Addison-Wesley 签名系列 
The Addison-Wesley Signature Series
Addison-Wesley Signature Series为读者提供有关计算机专业人士现代技术最新趋势的实用和权威信息。该系列基于一个简单的前提：伟大的书出自伟大的作者。该系列中的书籍由专家顾问、世界级作家亲自挑选。这些专家自豪地在封面上签名，他们的签名确保这些思想领袖与作者密切合作，以确定主题范围、书籍范围、关键内容和整体独特性。专家签名也象征着对我们读者的承诺：您正在阅读未来的经典之作。
The Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Books in the series are personally chosen by expert advisors, world-class authors in their own right. These experts are proud to put their signatures on the covers, and their signatures ensure that these thought leaders have worked closely with authors to define topic coverage, book scope, critical content, and overall uniqueness. The expert signatures also symbolize a promise to our readers: you are reading a future classic.
A DDISON -WESLEY签名系列_ _ _ _ _
THE ADDISON-WESLEY SIGNATURE SERIES
签名者：KENT B ECK & M ARTIN F OWLER
SIGNERS: KENT BECK & MARTIN FOWLER
Martin Fowler一直是企业应用程序中对象技术的先驱。他最关心的是如何设计好软件。他专注于深入了解如何构建可在未来持续使用的企业软件。他有兴趣从技术细节背后寻找持续多年的模式、实践和原则；这些书十年后应该可以使用。马丁的标准是这些是他希望自己能写的书。
Martin Fowler has been a pioneer of object technology in enterprise applications. His central concern is how to design software well. He focuses on getting to the heart of how to build enterprise software that will last well into the future. He is interested in looking behind the specifics of technologies to the patterns, practices, and principles that last for many years; these books should be usable a decade from now. Martin’s criterion is that these are books he wished he could write.
Kent Beck开创了以人为本的技术，如 JUnit、极限编程和软件开发模式。Kent 热衷于通过做好事来帮助团队做好事——找到一种同时满足经济、审美、情感和实际约束的软件开发风格。他的书着重于触及软件创建者和用户的生活。
Kent Beck has pioneered people-oriented technologies like JUnit, Extreme Programming, and patterns for software development. Kent is interested in helping teams do well by doing good – finding a style of software development that simultaneously satisfies economic, aesthetic, emotional, and practical constraints. His books focus on touching the lives of the creators and users of software.
系列中的标题
TITLES IN THE SERIES
实施模式
Kent Beck，ISBN 0321413091
Implementation Patterns
Kent Beck, ISBN 0321413091
测试驱动开发：通过示例
Kent Beck，ISBN：0321146530
Test-Driven Development: By Example
Kent Beck, ISBN: 0321146530
应用的用户故事：用于敏捷软件开发
Mike Cohn，ISBN：0321205685
User Stories Applied: For Agile Software Development
Mike Cohn, ISBN: 0321205685
实施精益软件开发：从概念到现金
Mary 和 Tom Poppendieck，ISBN 0321437381
Implementing Lean Software Development: From Concept to Cash
Mary and Tom Poppendieck, ISBN 0321437381
重构数据库：进化数据库设计
Scott W. Ambler 和 Pramodkumar J. Sadalage，ISBN 0321293533
Refactoring Databases: Evolutionary Database Design
Scott W. Ambler and Pramodkumar J. Sadalage, ISBN 0321293533
持续集成：提高软件质量和降低风险
Paul M. Duvall，与 Steve Matyas 和 Andrew Glover，0321336380
Continuous Integration: Improving Software Quality and Reducing Risk
Paul M. Duvall, with Steve Matyas and Andrew Glover, 0321336380
企业应用架构模式
Martin Fowler，ISBN：0321127420
Patterns of Enterprise Application Architecture
Martin Fowler, ISBN: 0321127420
重构 HTML：改进现有 Web 应用程序的设计
Elliotte Rusty Harold，ISBN 0321503635
Refactoring HTML: Improving the Design of Existing Web Applications
Elliotte Rusty Harold, ISBN 0321503635
超越软件架构：创建和维持成功的解决方案
Luke Hohmann，ISBN：0201775948
Beyond Software Architecture: Creating and Sustaining Winning Solutions
Luke Hohmann, ISBN: 0201775948
企业集成模式：设计、构建和部署消息传递解决方案
Gregor Hohpe 和 Bobby Woolf，ISBN：0321200683
Enterprise Integration Patterns: Desinging, Building, and Deploying Messaging Solutions
Gregor Hohpe and Bobby Woolf, ISBN: 0321200683
重构为模式
Joshua Kerievsky，ISBN 0321213351
Refactoring to Patterns
Joshua Kerievsky, ISBN 0321213351
应用的用户故事
User Stories Applied
对于敏捷软件开发
For Agile Software Development
波士顿•旧金山•纽约•多伦多•蒙特利尔
伦敦•慕尼黑•巴黎•马德里
开普敦•悉尼•东京•新加坡•墨西哥城
Boston • San Francisco • New York • Toronto • Montreal
London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
制造商和销售商用来区分其产品的许多名称都被声明为商标。如果这些名称出现在本书中，并且 Addison-Wesley 知道商标声明，则这些名称的首字母大写或全部大写。
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.
作者和出版商在本书的准备过程中已尽心尽力，但不作任何明示或暗示的保证，也不对错误或遗漏承担任何责任。对于与使用此处包含的信息或程序有关或因使用此处包含的信息或程序而引起的附带或间接损害不承担任何责任。
The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
批量购买和特价销售时，出版商为本书提供折扣。获取更多资讯，请联系：
The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact:
美国公司和政府销售
(800) 382-3419
corpsales@pearsontechgroup.com
U.S. Corporate and Government Sales
(800) 382-3419
corpsales@pearsontechgroup.com
对于美国以外的销售，请联系：
For sales outside of the U.S., please contact:
国际销售
(317) 581-3793
international@pearsontechgroup.com
International Sales
(317) 581-3793
international@pearsontechgroup.com
在 Web 上访问 Addison-Wesley：www.awprofessional.com
Visit Addison-Wesley on the Web: www.awprofessional.com
美国国会图书馆出版数据编目
Library of Congress Cataloging-in-Publication Data
可以从国会图书馆获得本书的目录记录
A catalog record for this book can be obtained from the Library of Congress
版权所有 © 2004 Pearson Education, Inc.
Copyright © 2004 by Pearson Education, Inc.
版权所有。未经出版商事先同意，不得以任何形式或通过任何方式（电子、机械、影印、录音或其他方式）复制、存储在检索系统中或传播本出版物的任何部分。在美利坚合众国印刷。在加拿大同步出版。
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada.
有关获得使用本作品材料许可的信息，请将书面请求提交至：
For information on obtaining permission for use of material from this work, please submit a written request to:
Pearson Education, Inc.
Rights and Contracts Department
75 Arlington Street, Suite 300
Boston, MA 02116
传真：(617) 848-7047
Pearson Education, Inc.
Rights and Contracts Department
75 Arlington Street, Suite 300
Boston, MA 02116
Fax: (617) 848-7047
国际标准书号：0-321-20568-5
ISBN: 0-321-20568-5
在美国印第安纳州克劳福兹维尔的 RR Donnelley Crawfordsville 的再生纸上印刷的文本。
Text printed in the United States on recycled paper at RR Donnelley Crawfordsville in Crawfordsville, Indiana.
2009 年 2 月第 13 次印刷
13th printing, February 2009
内容
Contents
“How Long Does It Have to Be?”
What Will the Process Be Like?
Planning Releases and Iterations
Valuable to Purchasers or Users
Elicitation and Capture Should Be Illicit
Chapter 5. Working with User Proxies
Trainers and Technical Support
What to Do When Working with a User Proxy
Constituting the Customer Team
Chapter 6. Acceptance Testing User Stories
The Customer Specifies the Tests
Testing Is Part of the Process
The Framework for Integrated Test
Chapter 7. Guidelines for Good Stories
Keep the UI Out as Long as Possible
Include User Roles in the Stories
PART II: Estimating and Planning
Chapter 8. Estimating User Stories
Prioritizing Infrastructural Needs
From Story Points to Expected Duration
Chapter 10. Planning an Iteration
Chapter 11. Measuring and Monitoring Velocity
Burndown Charts During an Iteration
PART III: Frequently Discussed Topics
Chapter 12. What Stories Are Not
User Stories Are Not Use Cases
User Stories Are Comprehensible
User Stories Are the Right Size for Planning
User Stories Work for Iterative Development
Stories Encourage Deferring Detail
Stories Support Opportunistic Development
User Stories Encourage Participatory Design
Stories Build Up Tacit Knowledge
Chapter 14. A Catalog of Story Smells
Including User Interface Detail Too Soon
Customer Has Trouble Prioritizing
Customer Won’t Write and Prioritize the Stories
Chapter 15. Using Stories with Scrum
Scrum Is Iterative and Incremental
Handling NonFunctional Requirements
User Stories and the User Interface
Identifying Some Initial Roles
Stories for a Non-Sailing Gift Buyer
Chapter 19. Estimating the Stories
Chapter 21. The Acceptance Tests
Appendix A. An Overview of Extreme Programming
Appendix B. Answers to Questions
Chapter 5, Working with User Proxies
Chapter 6, Acceptance Testing User Stories
Chapter 7, Guidelines for Good Stories
Chapter 8, Estimating User Stories
Chapter 10, Planning an Iteration
Chapter 11, Measuring and Monitoring Velocity
Chapter 12, What Stories Are Not
Chapter 14, A Catalog of Story Smells
前言
Foreword
你如何决定一个软件系统应该做什么？然后，您如何在受影响的各个人之间传达该决定？本书解决了这个复杂的问题。这个问题很难，因为每个参与者都有不同的需求。项目经理想要跟踪进度。程序员想要实现这个系统。产品经理需要灵活性。测试人员想要测量。用户想要一个有用的系统。在这些观点之间制造富有成效的冲突，做出每个人都可以支持的单一集体决定，并在数月或数年内保持这种平衡，这些都是困难的问题。
How do you decide what a software system is supposed to do? And then, how do you communicate that decision between the various people affected? This book takes on this complicated problem. The problem is difficult because each participant has different needs. Project managers want to track progress. Programmers want to implement the system. Product managers want flexibility. Testers want to measure. Users want a useful system. Creating productive conflict between these perspectives, coming to a single collective decision everyone can support, and maintaining that balance for months or years are all difficult problems.
Mike Cohn 在本书User Stories Applied中探讨的解决方案与以前解决此问题的尝试在表面上是相同的——需求、用例和场景。什么事这么复杂？你写下你想做什么，然后你就去做。解决方案的激增表明问题并不像看起来那么简单。变化归结为您写下的内容和时间。
The solution Mike Cohn explores in this book, User Stories Applied, is superficially the same as previous attempts to solve this problem—requirements, use cases, and scenarios. What’s so complicated? You write down what you want to do and then you do it. The proliferation of solutions suggests that the problem is not as simple as it appears. The variation comes down to what you write down and when.
用户故事通过只写下两条信息来开始这个过程：系统要满足的每个目标和满足该目标的粗略成本。这只需要几句话就可以为您提供其他方法所没有的信息。使用“最后负责时刻”的原则，团队推迟到实施之前才写下功能的大部分细节。
User stories start the process by writing down just two pieces of information: each goal to be satisfied by the system and the rough cost of satisfying that goal. This takes just a few sentences and gives you information other approaches don’t. Using the principle of the “last responsible moment,” the team defers writing down most details of the features until just before implementation.
这种简单的时移有两个主要影响。首先，团队可以轻松地在开发周期的早期开始实施“最有趣”的功能，而其他功能仍然模糊不清。自动测试指定每个功能的详细信息，确保早期功能在您添加新功能时继续按指定运行。其次，尽早为功能定价可以鼓励从一开始就确定优先级，而不是在最后为了满足交付日期而惊慌失措地放弃范围。
This simple time shift has two major effects. First, the team can easily begin implementing the “juiciest” features early in the development cycle while the other features are still vague. The automated tests specifying the details of each feature ensure that early features continue to run as specified as you add new features. Second, putting a price on features early encourages prioritizing from the beginning instead of a panicked abortion of scope at the end in order to meet a delivery date.
Mike 在用户故事方面的经验使这本书充满了使用户故事为您的开发团队工作的实用建议。祝你清晰、自信地发展。
Mike’s experience with user stories makes this a book full of practical advice for making user stories work for your development team. I wish you clear, confident development.
肯特·贝克
Kent Beck
三河学院
Three Rivers Institute
致谢
Acknowledgments
本书从许多审稿人的评论中受益匪浅。我特别感谢 Marco Abis、Dave Astels、Steve Bannerman、Steve Berczuk、Lyn Bain、Dan Brown、Laura Cohn、Ron Crocker、Ward Cunningham、Rachel Davies、Robert Ellsworth、Doris Ford、John Gilman、Sven Gorts、Deb Hartmann、Chris Leslie、Chin Keong Ling、Phlip、Keith Ray、Michele Sliger、Jeff Tatelman、Anko Tijman、Trond Wingård、Jason Yip 和一些匿名审稿人。
This book has benefitted greatly from comments from many reviewers. In particular I thank Marco Abis, Dave Astels, Steve Bannerman, Steve Berczuk, Lyn Bain, Dan Brown, Laura Cohn, Ron Crocker, Ward Cunningham, Rachel Davies, Robert Ellsworth, Doris Ford, John Gilman, Sven Gorts, Deb Hartmann, Chris Leslie, Chin Keong Ling, Phlip, Keith Ray, Michele Sliger, Jeff Tatelman, Anko Tijman, Trond Wingård, Jason Yip, and a handful of anonymous reviewers.
衷心感谢我的正式审稿人：Ron Jeffries、Tom Poppendieck 和 Bill Wake。罗恩让我保持诚实和敏捷。汤姆让我看到了许多我以前没有考虑过的想法。比尔让我走上正轨，并与我分享了他的 INVEST 首字母缩写词。本书得到了不可估量的改进，每一位优秀的人都提出了建议，我很自豪能与之共事。
My sincerest thanks to my formal reviewers: Ron Jeffries, Tom Poppendieck, and Bill Wake. Ron kept me honest and agile. Tom opened my eyes to many ideas I hadn’t considered before. Bill kept me on track and shared with me his INVEST acronym. This book has been immeasurably improved by suggestions from each of these fine individuals with whom I am proud to have worked.
我还要感谢Testing Extreme Programming的作者 Lisa Crispin，她告诉我她在 Addison-Wesley 的愉快经历，鼓励我写这本书。没有她的鼓励，我永远不会开始。
I also thank Lisa Crispin, author of Testing Extreme Programming, who encouraged me to write this book by telling me about her pleasant experience with Addison-Wesley. Without her encouragement, I never would have started.
在过去的九年里，我所知道的大部分内容都是我与托德戈尔丁争论过的。托德和我同意的次数比我们任何人都知道的要多，但我总能从我们的争论中学到一些东西。我很感激 Tod 这些年来教给我的一切。由于我与他的交谈，这本书的大部分内容都得到了极大的丰富。
Most of what I know I’ve argued about with Tod Golding over the last nine years. Tod and I agree more often than either of us knows, but I always learn something from our arguments. I am indebted to Tod for all he’s taught me over the years. Much of this book has been greatly enriched because of my conversations with him.
感谢 Alex Viggio 和 XP Denver 的每个人，在那里我能够展示本书中许多想法的早期版本。还要感谢 Mark Mosholder 和 JB Rainsberger，他们与我谈论了他们如何使用软件而不是记事卡。感谢 Kenny Rubin，他是与 Adele Goldberg 合着的Succeeding With Objects的合著者，她对他们的书的明显自豪感让我想在几年后再次写作。
Thanks to Alex Viggio and everyone at XP Denver where I was able to present an early version of many of the ideas in this book. Thank you, also, to Mark Mosholder and J. B. Rainsberger, who talked to me about how they use software instead of note cards. Thank you to Kenny Rubin, co-author of Succeeding With Objects with Adele Goldberg, whose obvious pride in their book helped me want to write again after a few years off.
衷心感谢 Fast401k 的创始人 Mark 和 Dan Gutrich，他们全心全意地接受了用户故事和 Scrum。还要感谢我在 Fast401k 的每一位同事，我们正在朝着成为科罗拉多州最好的团队之一的目标迈进。
A hearty thank you to Mark and Dan Gutrich, the founders of Fast401k, who have wholeheartedly embraced user stories and Scrum. Thank you as well to each of my coworkers at Fast401k, where we are well on our way to achieving our goal of being one of the best teams in Colorado.
没有办法感谢我的家人，感谢他们在没有我的情况下所做的一切。感谢我出色的女儿和公主萨凡纳和德莱尼。特别感谢我出色而美丽的妻子劳拉，即使我做的很少，她也做了很多。
There is no way to thank my family enough for all the time they did without me. Thank you to my wonderful daughters and princesses, Savannah and Delaney. A special thank you to my wonderful and beautiful wife, Laura, for doing so much even when I do so little.
我非常感谢 Addison-Wesley 的团队。Paul Petralia 让这个过程从头到尾都很愉快。Michele Vincenti 让事情继续前进。Lisa Iarkowski 为我提供了无价的 FrameMaker 帮助。Gail Cocker 使我的插图值得一看。尼克·拉德胡伯 (Nick Radhuber) 最后将这一切融合在一起。
I owe a huge debt of gratitude to the team at Addison-Wesley. Paul Petralia made the process enjoyable from start to finish. Michele Vincenti kept things moving. Lisa Iarkowski offered me invaluable FrameMaker help. Gail Cocker made my illustrations worth looking at. And Nick Radhuber brought it all together at the end.
最后，但并非最不重要的一点是，感谢肯特·贝克 (Kent Beck) 的精彩见解和时间，并将本书收录在他的签名系列中。
And last, but far from least, thank you to Kent Beck for his wonderful insights, his time, and for including this book in his Signature Series.
介绍
Introduction
在 90 年代中期的大部分时间里，我都感到内疚。我在一家公司工作，该公司每年大约收购一家新公司。每次我们收购一家新公司时，我都会被指派管理他们的软件开发团队。每个被收购的开发团队都带来了光彩夺目的、漂亮的、冗长的需求文档。我不可避免地感到内疚，因为我自己的团队没有制定出如此漂亮的需求规格说明书。然而，我的团队在生产软件方面一直比我们收购的团队成功得多。
I felt guilty throughout much of the mid-1990s. I was working for a company that was acquiring about one new company each year. Every time we’d buy a new company I would be assigned to run their software development group. And each of the acquired development groups came with glorious, beautiful, lengthy requirements documents. I inevitably felt guilty that my own groups were not producing such beautiful requirements specifications. Yet, my groups were consistently far more successful at producing software than were the groups we were acquiring.
我知道我们正在做的事情奏效了。然而，我有一种挥之不去的感觉，即如果我们编写大而冗长的需求文档，我们可能会更加成功。毕竟，那是我当时阅读的书籍和文章中所写的内容。如果成功的软件开发团队正在编写出色的需求文档，那么我们似乎也应该这样做。但是，我们从来没有时间。我们的项目总是太重要，而且需要的时间太早，以至于我们无法在一开始就拖延它们。
I knew that what we were doing worked. Yet I had this nagging feeling that if we’d write big, lengthy requirements documents we could be even more successful. After all, that was what was being written in the books and articles I was reading at the time. If the successful software development teams were writing glorious requirements documents then it seemed like we should do the same. But, we never had the time. Our projects were always too important and were needed too soon for us to delay them at the start.
因为我们从来没有时间写出漂亮、冗长的需求文档，所以我们决定采用一种与用户交谈的工作方式。我们没有把事情写下来，来回传递，在时间用完时进行谈判，而是交谈。我们会在纸上绘制屏幕样本，有时我们会制作原型，通常我们会编写一些代码，然后向目标用户展示我们编写的代码。至少每个月一次，我们会抓住一组有代表性的用户，并向他们准确展示编码的内容。通过贴近我们的用户并向他们展示小块的进展，我们找到了一种在没有漂亮的需求文档的情况下取得成功的方法。
Because we never had the time to write a beautiful, lengthy requirements document, we settled on a way of working in which we would talk with our users. Rather than writing things down, passing them back and forth, and negotiating while the clock ran out, we talked. We’d draw screen samples on paper, sometimes we’d prototype, often we’d code a little and then show the intended users what we’d coded. At least once a month we’d grab a representative set of users and show them exactly what had been coded. By staying close to our users and by showing them progress in small pieces, we had found a way to be successful without the beautiful requirements documents.
尽管如此，我还是感到内疚，因为我们没有按照我认为应该做的方式做事。
Still, I felt guilty that we weren’t doing things the way I thought we were supposed to.
1999 年，Kent Beck 的革命性小书《Extreme Programming Explained: Embrace Change》发行了。一夜之间，我所有的罪恶感都烟消云散了。有人说开发人员和客户可以交谈而不是写、协商，然后再写一些。肯特澄清了很多事情并给了我许多新的工作方式。但是，最重要的是，他证明了我从自己的经验中学到的东西。
In 1999 Kent Beck’s revolutionary little book, Extreme Programming Explained: Embrace Change, was released. Overnight all of my guilt went away. Here was someone saying it was OK for developers and customers to talk rather than write, negotiate, and then write some more. Kent clarified a lot of things and gave me many new ways of working. But, most importantly, he justified what I’d learned from my own experience.
广泛的前期需求收集和文档可以在很多方面扼杀一个项目。最常见的一种情况是需求文档本身成为目标。只有当它有助于实现交付某些软件的真正目标时，才应该编写需求文档。
Extensive upfront requirements gathering and documentation can kill a project in many ways. One of the most common is when the requirements document itself becomes a goal. A requirements document should be written only when it helps achieve the real goal of delivering some software.
广泛的前期需求收集和文档可以扼杀项目的第二种方式是书面语言的不准确。我记得很多年前有人讲过一个孩子洗澡的故事。孩子的父亲已经把浴缸装满水，正在扶着孩子下水。这个年幼的孩子，可能只有两三岁，将脚趾浸入水中，迅速将其移开，然后告诉她父亲“让它暖和一点”。父亲把手伸进水里，惊讶地发现水并没有太冷，反而比女儿习惯的水温还高。
A second way that extensive upfront requirements gathering and documentation can kill a project is through the inaccuracies of written language. I remember many years ago being told a story about a child at bath time. The child’s father has filled the bath tub and is helping his child into the water. The young child, probably two or three years old, dips a toe in the water, quickly removes it, and tells her father “make it warmer.” The father puts his hand into the water and is surprised to find that, rather than too cold, the water is already warmer than what his daughter is used to.
思考了片刻孩子的要求后，这位父亲意识到他们的沟通有误，是在用同样的词表达不同的意思。孩子要求“让它更暖和”的要求被任何成年人解释为“提高温度”。然而，对孩子来说，“让它更暖和”意味着“让它更接近我称之为温暖的温度”。
After thinking about his child’s request for a moment, the father realizes they are miscommunicating and are using the same words to mean different things. The child’s request to “make it warmer” is interpreted by any adult to be the same as “increase the temperature.” To the child, however, “make it warmer” meant “make it closer to the temperature I call warm.”
文字，尤其是书面文字，是一种非常薄的媒介，通过它来表达对像软件这样复杂的东西的需求。由于它们容易被误解，我们需要用开发人员、客户和用户之间的频繁对话来代替书面文字。用户故事为我们提供了一种方式，可以让我们记下足够多的内容，我们不会忘记，我们可以估算和计划，同时也鼓励这次交流。
Words, especially when written, are a very thin medium through which to express requirements for something as complex as software. With their ability to be misinterpreted we need to replace written words with frequent conversations between developers, customers, and users. User stories provide us with a way of having just enough written down that we don’t forget and that we can estimate and plan while also encouraging this time of communication.
当你读完本书的第一部分时，你将准备好开始从严格写下每一个最后的需求细节的转变。读完本书后，您将了解在您的环境中实施故事驱动流程所需的一切。本书分为四个部分和两个附录。
By the time you’ve finished the first part of this book you will be ready to begin the shift away from rigorously writing down every last requirement detail. By the time you’ve finished the book you will know everything necessary to implement a story-driven process in your environment. This book is organized in four parts and two appendices.
- 第 I 部分：入门 - 描述了今天开始撰写故事所需了解的一切。用户故事的目标之一是让人们谈论而不是写作。第一部分的目标是让您尽快开口。第一章概述了什么是用户故事以及如何使用故事。第 I 部分的后续章节提供了有关编写用户故事、通过用户角色建模收集故事、在无法访问真实最终用户时编写故事以及测试用户故事的更多详细信息。第一部分以一章结尾，提供了可改进用户故事的指南。
- Part I: Getting Started—A description of everything you need to know to get started writing stories today. One of the goals of user stories is to get people talking rather than writing. It is the goal of Part I to get you talking as soon as possible. The first chapter provides an overview of what a user story is and how you’ll use stories. The next chapters in Part I provide additional detail on writing user stories, gathering stories through user role modeling, writing stories when you don’t have access to real end users, and testing user stories. Part I concludes with a chapter providing guidelines that will improve your user stories.
- 第二部分：估算和规划——配备了一系列用户故事，我们经常需要回答的第一件事是“开发需要多长时间？” 第二部分的章节涵盖了如何以故事点来估计故事，如何在三到六个月的时间范围内计划发布，如何更详细地计划随后的迭代，最后，如何衡量进度和评估项目是否按照您的意愿进行。
- Part II: Estimating and Planning—Equipped with a collection of user stories, one of the first things we often need to answer is “How long will it take to develop?” The chapters of Part II cover how to estimate stories in story points, how to plan a release over a three- to six-month time horizon, how to plan an ensuing iteration in more detail, and, finally, how to measure progress and assess whether the project is progressing as you’d like.
- 第 III 部分：经常讨论的主题——第 III 部分首先描述故事与需求备选方案（例如用例、软件需求规范和交互设计场景）有何不同。第 III 部分的后续章节着眼于用户故事的独特优势，如何判断出现问题的时间，以及如何使敏捷过程 Scrum 适应使用故事。第三部分的最后一章着眼于各种较小的问题，例如是在纸质记事卡上还是在软件系统中写故事，以及如何处理非功能性需求。
- Part III: Frequently Discussed Topics—Part III starts by describing how stories differ from requirements alternatives such as use cases, software requirements specifications, and interaction design scenarios. The next chapters in Part III look at the unique advantages of user stories, how to tell when something is going wrong, and how to adapt the agile process Scrum to use stories. The final chapter of Part III looks at a variety of smaller issues such as whether to writes stories on paper note cards or in a software system and how to handle nonfunctional requirements.
- 第 IV 部分：示例——一个扩展示例，旨在帮助将所有内容整合在一起。如果我们要宣称开发人员可以通过故事最好地理解用户的需求，那么用一个扩展的故事来结束本书是很重要的，该故事将用户故事的所有方面都集中在一个示例中。
- Part IV: An Example—An extended example intended to help bring everything together. If we’re to make the claim that developers can best understand user’s needs through stories then it is important to conclude this book with an extended story showing all aspects of user stories brought together in one example.
- 第五部分：附录——用户故事起源于极限编程。阅读本书无需熟悉极限编程。但是，附录 A中提供了对极限编程的简要介绍。附录 B包含各章结尾问题的答案。
- Part V: Appendices—User stories originate in Extreme Programming. You do not need to be familiar with Extreme Programming in order to read this book. However, a brief introduction to Extreme Programming is provided in Appendix A. Appendix B contains answers to the questions that conclude the chapters.
第一部分：入门
Part I: Getting Started
在第 I 部分中，我们首先快速浏览一下什么是用户故事以及如何使用它们。之后，我们将更详细地了解如何编写用户故事，如何使用系统的用户类型来帮助识别故事，如何在难以找到用户时与可能填补用户角色的人合作，以及如何编写用于了解故事何时成功编码的测试。毕竟，我们将通过查看好故事的一些指南来结束第 I部分。
In Part I, we start with a quick tour of what user stories are and how they’re used. Following that we will look in more detail at how to write user stories, how to use the system’s user types to help identify stories, how to work with people who may fill the user role when users themselves are hard to come by, and how to write tests that are used to know when a story has been successfully coded. After all that, we’ll close Part I by looking at some guidelines for good stories.
完成本节后，您将掌握足够的知识，可以开始识别、编写和测试您自己的故事。您还将准备了解如何使用用户案例进行估算和规划，这将是第 II 部分的主题。
When you’re done with this section you’ll know enough to get started with identifying, writing, and testing your own stories. You’ll also be ready to look at how to estimate and plan with user stories, which will be the topic of Part II.
第 1 章概述
Chapter 1. An Overview
软件需求是一个沟通问题。想要新软件（使用或销售）的人必须与将构建新软件的人沟通。为了取得成功，一个项目依赖于来自截然不同的人的头脑中的信息：一方面是客户和用户，有时是分析师、领域专家和其他从业务或组织角度看待软件的人；另一边是技术团队。
Software requirements is a communication problem. Those who want the new software (either to use or to sell) must communicate with those who will build the new software. To succeed, a project relies on information from the heads of very different people: on one side are customers and users and sometimes analysts, domain experts and others who view the software from a business or organizational perspective; on the other side is the technical team.
如果任何一方主导这些沟通，该项目就会失败。当业务方占主导地位时，它会强制要求功能和日期，而不太关心开发人员能否满足这两个目标，或者开发人员是否确切了解需要什么。当开发人员主导沟通时，技术行话取代了业务语言，开发人员失去了通过倾听来了解需要什么的机会。
If either side dominates these communications, the project loses. When the business side dominates, it mandates functionality and dates with little concern that the developers can meet both objectives, or whether the developers understand exactly what is needed. When the developers dominate the communications, technical jargon replaces the language of the business and the developers lose the opportunity to learn what is needed by listening.
我们需要的是一种共同努力的方式，这样任何一方都不会占主导地位，让资源分配中充满情感和政治的问题成为一个共同的问题。当资源分配问题完全落在一边时，项目就会失败。如果开发人员承担了这个问题（通常以被告知“我不在乎你怎么做，但在 6 月之前全部完成”的形式），他们可能会以质量换取额外的功能，可能只是部分实现一个功能，或者可能只做出客户和用户应参与的许多决策中的任何一个。当客户和用户承担资源分配的负担时，我们通常会在项目开始时看到一系列冗长的讨论，在此期间逐渐从项目中删除功能。然后，当软件最终交付时，
What we need is a way to work together so that neither side dominates and so that the emotionally-fraught and political issue of resource allocation becomes a shared problem. Projects fail when the problem of resource allocation falls entirely on one side. If the developers shoulder the problem (usually in the form of being told “I don’t care how you do it but do it all by June”) they may trade quality for additional features, may only partially implement a feature, or may solely make any of a number of decisions in which the customers and users should participate. When customers and users shoulder the burden of resource allocation, we usually see a lengthy series of discussions at the start of a project during which features are progressively removed from the project. Then, when the software is eventually delivered, it has even less functionality than the reduced set that was identified.
到目前为止，我们已经了解到我们无法完美地预测软件开发项目。当用户看到该软件的早期版本时，他们会产生新的想法并改变他们的观点。由于软件的无形性，大多数开发人员都很难估计需要多长时间。由于这些和其他因素，我们无法绘制出完美的 PERT 图来显示项目中必须完成的所有工作。
By now we’ve learned that we cannot perfectly predict a software development project. As users see early versions of the software, they come up with new ideas and their opinions change. Because of the intangibility of software, most developers have a notoriously difficult time estimating how long things will take. Because of these and other factors we cannot lay out a perfect PERT chart showing everything that must be done on a project.
我们根据手头的信息做出决定。我们经常这样做。我们不是在项目一开始就做出一套包罗万象的决策，而是将决策制定贯穿项目的整个过程。为了做到这一点，我们确保我们有一个流程，可以尽可能早和经常地获取信息。这就是用户故事的用武之地。
We make decisions based on the information we have at hand. And we do it often. Rather than making one all-encompassing set of decisions at the outset of a project, we spread the decision-making across the duration of the project. To do this we make sure we have a process that gets us information as early and often as possible. And this is where user stories come in.
什么是用户故事？
What Is a User Story?
用户故事描述了对系统或软件的用户或购买者有价值的功能。用户故事由三个方面组成：
A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects:
- 用于计划和提醒的故事的书面描述
- a written description of the story used for planning and as a reminder
- 关于故事的对话有助于充实故事的细节
- conversations about the story that serve to flesh out the details of the story
- 传达和记录细节并可用于确定故事何时完成的测试
- tests that convey and document details and that can be used to determine when a story is complete
由于用户故事描述传统上是手写在纸质记事卡上的，Ron Jeffries 将这三个方面用卡片、对话和确认的美妙头韵命名（Jeffries 2001）。卡片可能是用户故事最明显的体现，但它并不是最重要的。雷切尔·戴维斯 (Rachel Davies) (2001)曾说过，卡片“代表客户需求，而不是记录它们”。这是思考用户故事的完美方式：虽然卡片可能包含故事的文本，但细节在对话中制定并记录在确认中。
Because user story descriptions are traditionally hand-written on paper note cards, Ron Jeffries has named these three aspects with the wonderful alliteration of Card, Conversation, and Confirmation (Jeffries 2001). The Card may be the most visible manifestation of a user story, but it is not the most important. Rachel Davies (2001) has said that cards “represent customer requirements rather than document them.” This is the perfect way to think about user stories: While the card may contain the text of the story, the details are worked out in the Conversation and recorded in the Confirmation.
作为示例用户故事，请参阅Story Card 1.1，这是来自假设的 BigMoneyJobs 职位发布和搜索网站的故事卡。
As an example user story see Story Card 1.1, which is a story card from the hypothetical BigMoneyJobs job posting and search website.
故事卡 1.1。写在便条卡上的初始用户故事。
Story Card 1.1. An initial user story written on a note card.
为了保持一致性，本书其余部分的许多示例都将针对 BigMoneyJobs 网站。BigMoneyJobs 的其他示例故事可能包括：
For consistency, many of the examples throughout the rest of this book will be for the BigMoneyJobs website. Other sample stories for BigMoneyJobs might include:
- 用户可以搜索工作。
- A user can search for jobs.
- 公司可以发布新的职位空缺。
- A company can post new job openings.
- 用户可以限制谁可以看到她的简历。
- A user can limit who can see her resume.
因为用户故事代表了用户会看重的功能，所以下面的例子对于这个系统来说并不是很好的用户故事：
Because user stories represent functionality that will be valued by users, the following examples do not make good user stories for this system:
- 该软件将用 C++ 编写。
- The software will be written in C++.
- 该程序将通过连接池连接到数据库。
- The program will connect to the database through a connection pool.
第一个示例对于 BigMoneyJobs 来说不是一个好的用户故事，因为它的用户不会关心使用的是哪种编程语言。然而，如果这是一个应用程序编程接口，那么该系统的用户（她自己是一名程序员）很可能会写下“该软件将用 C++ 编写”。
The first example is not a good user story for BigMoneyJobs because its users would not care which programming language was used. However, if this were an application programming interface, then the user of that system (herself a programmer) could very well have written that “the software will be written in C++.”
在这种情况下，第二个故事不是一个好的用户故事，因为该系统的用户不关心应用程序如何连接到数据库的技术细节。
The second story is not a good user story in this case because the users of this system do not care about the technical details of how the application connects to the database.
也许您已经阅读了这些故事并且尖叫着“但是等等——在我的系统中使用连接池是必需的！” 如果是这样，等等，关键是故事应该写得让客户重视。有多种方法可以以对客户有价值的方式来表达此类故事。我们将在第 2 章“编写故事”中看到这样做的示例。
Perhaps you’ve read these stories and are screaming “But wait—using a connection pool is a requirement in my system!” If so, hold on, the key is that stories should be written so that the customer can value them. There are ways to express stories like these in ways that are valuable to a customer. We’ll see examples of doing that in Chapter 2, “Writing Stories.”
细节在哪里？
Where Are the Details?
说“用户可以搜索工作”是一回事。仅以此为指导就可以开始编码和测试是另一回事。详情在哪里？那么所有未回答的问题呢，比如：
It’s one thing to say “A user can search for jobs.” It’s another thing to be able to start coding and testing with only that as guidance. Where are the details? What about all the unanswered questions like:
- 用户可以搜索哪些值？状态？城市？职称？关键词？
- What values can users search on? State? City? Job title? Keywords?
- 用户是否必须是网站的会员？
- Does the user have to be a member of the site?
- 可以保存搜索参数吗？
- Can search parameters be saved?
- 匹配工作显示什么信息？
- What information is displayed for matching jobs?
其中许多细节可以表示为附加故事。事实上，拥有更多的故事比拥有太大的故事更好。例如，整个 BigMoneyJobs 网站大概就是用这两个故事来描述的：
Many of these details can be expressed as additional stories. In fact, it is better to have more stories than to have stories that are too large. For example, the entire BigMoneyJobs site is probably described by these two stories:
显然，这两个故事太大了，用处不大。第 2 章“编写故事”完全解决了故事大小的问题，但作为一个起点，最好让一个或一对程序员在半天到两周的时间内编写和测试故事。从广义上讲，上面的两个故事可以很容易地涵盖 BigMoneyJobs 网站的大部分内容，因此每个故事都可能需要大多数程序员花费一个多星期的时间。
Clearly these two stories are too large to be of much use. Chapter 2, “Writing Stories,” fully addresses the question of story size, but as a starting point it’s good to have stories that can be coded and tested between half a day and perhaps two weeks by one or a pair of programmers. Liberally interpreted, the two stories above could easily cover the majority of the BigMoneyJobs site so each will likely take most programmers more than a week.
当一个故事太大时，它有时被称为史诗。史诗可以分成两个或多个更小的故事。例如，史诗“用户可以搜索工作”可以拆分为以下故事：
When a story is too large it is sometimes referred to as an epic. Epics can be split into two or more stories of smaller size. For example, the epic “A user can search for a job” could be split into these stories:
- 用户可以按位置、薪资范围、职位、公司名称和职位发布日期等属性搜索职位。
- A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted.
- 用户可以查看有关搜索匹配的每个职位的信息。
- A user can view information about each job that is matched by a search.
- 用户可以查看有关已发布职位的公司的详细信息。
- A user can view detailed information about a company that has posted a job.
但是，在我们有一个涵盖所有细节的故事之前，我们不会继续拆分故事。例如，“用户可以查看与搜索匹配的每个职位的信息”这个故事是一个非常合理和现实的故事。我们不需要进一步将其分为：
However, we do not continue splitting stories until we have a story that covers every last detail. For example, the story “A user can view information about each job that is matched by a search” is a very reasonable and realistic story. We do not need to further divide it into:
- 用户可以查看职位描述。
- A user can view a job description.
- 用户可以查看职位的薪资范围。
- A user can view a job’s salary range.
- 用户可以查看作业的位置。
- A user can view the location of a job.
同样，用户故事不需要像这样以典型的需求文档样式进行扩充：
Similarly, the user story does not need to be augmented in typical requirements documentation style like this:
4.6) 用户可以查看与搜索匹配的每个职位的信息。
4.6) A user can view information about each job that is matched by a search.
4.6.1) 用户可以查看职位描述。
4.6.1) A user can view the job description.
4.6.2) 用户可以查看职位的薪资范围。
4.6.2) A user can view a job’s salary range.
4.6.3) 用户可以查看作业的位置。
4.6.3) A user can view the location of a job.
与其将所有这些细节都写成故事，不如让开发团队和客户讨论这些细节是更好的方法。也就是说，在细节变得重要时就细节进行对话。根据以下内容在故事卡上做一些注释没有错讨论，如故事卡 1.2所示。然而，对话才是关键，而不是故事卡上的注释。开发人员和客户都不能在三个月后指着卡片说，“但是，看，我就这么说了。” 故事不是合同义务。正如我们将看到的，协议由证明故事已正确开发的测试记录。
Rather than writing all these details as stories, the better approach is for the development team and the customer to discuss these details. That is, have a conversation about the details at the point when the details become important. There’s nothing wrong with making a few annotations on a story card based on a discussion, as shown in Story Card 1.2. However, the conversation is the key, not the note on the story card. Neither the developers nor the customer can point to the card three months later and say, “But, see I said so right there.” Stories are not contractual obligations. As we’ll see, agreements are documented by tests that demonstrate that a story has been developed correctly.
故事卡 1.2。带有注释的故事卡。
Story Card 1.2. A story card with a note.
“需要多长时间？”
“How Long Does It Have to Be?”
我是高中文学课上的孩子，他总是问，“它需要多长时间？” 每当我们被分配写一篇论文时。老师们从来都不喜欢这个问题，但我仍然认为这是一个公平的问题，因为它告诉我他们的期望是什么。了解项目用户的期望同样重要。这些期望最好以验收测试的形式体现。
I was the kid in high school literature classes who always asked, “How long does it have to be?” whenever we were assigned to write a paper. The teachers never liked the question but I still think it was a fair one because it told me what their expectations were. It is just as important to understand the expectations of a project’s users. Those expectations are best captured in the form of the acceptance tests.
如果您使用的是纸质记事卡，您可以将卡片翻过来并在那里记录这些期望。期望被写成提醒如何测试故事卡 1.3中所示的故事。如果您使用的是电子系统，它可能有一个地方可以让您输入验收测试提醒。
If you’re using paper note cards, you can turn the card over and capture these expectations there. The expectations are written as reminders about how to test the story as shown in Story Card 1.3. If you’re using an electronic system it probably has a place you can enter the acceptance test reminders.
故事卡 1.3。故事卡的背面提醒您如何测试故事。
Story Card 1.3. The back of a story card holds reminders about how to test the story.
测试说明应该简短且不完整。可以随时添加或删除测试。目标是传达有关故事的更多信息，以便开发人员知道他们何时完成。正如我的老师的期望对我知道我什么时候写完Moby Dick很有用一样，开发人员了解客户的期望也很有用，这样他们就知道什么时候完成了。
The test descriptions are meant to be short and incomplete. Tests can be added or removed at any time. The goal is to convey additional information about the story so that the developers will know when they are done. Just as my teacher’s expectations were useful to me in knowing when I was done writing about Moby Dick, it is useful for the developers to know the customer’s expectations so they know when they are done.
客户团队
The Customer Team
在一个理想的项目中，我们会有一个人优先考虑开发人员的工作，无所不知地回答他们的问题，在软件完成后使用它，并编写所有的故事。这几乎总是令人望而却步，因此我们建立了一个客户团队。客户团队包括确保软件满足其预期用户需求的人员。这意味着客户团队可能包括测试人员、产品经理、真实用户和交互设计师。
On an ideal project we would have a single person who prioritizes work for developers, omnisciently answers their questions, will use the software when it’s finished, and writes all of the stories. This is almost always too much to hope for, so we establish a customer team. The customer team includes those who ensure that the software will meet the needs of its intended users. This means the customer team may include testers, a product manager, real users, and interaction designers.
过程会怎样？
What Will the Process Be Like?
使用故事的项目将具有与您可能习惯的不同的感觉和节奏。使用传统的面向瀑布的流程会导致编写所有需求、分析需求、设计解决方案、编写解决方案代码，然后最后对其进行测试的循环。很多时候在这种类型的过程中，客户和用户在开始编写需求和最后接受软件时都会参与进来，但是用户和客户的参与可能在需求和接受之间几乎完全消失。到目前为止，我们已经知道这是行不通的。
A project that is using stories will have a different feel and rhythm than you may be used to. Using a traditional waterfall-oriented process leads to a cycle of write all the requirements, analyze the requirements, design a solution, code the solution, and then finally test it. Very often during this type of process, customers and users are involved at the beginning to write requirements and at the end to accept the software, but user and customer involvement may almost entirely disappear between requirements and acceptance. By now, we’ve learned that this doesn’t work.
在故事驱动的项目中，您会注意到的第一件事是客户和用户在整个项目期间始终参与其中。他们不应该（或不允许！）在项目进行期间消失。无论团队将使用极限编程（XP；参见附录 A，“极限编程概述”以获取更多信息）、统一过程的敏捷版本，还是像 Scrum 这样的敏捷过程（参见第 15 章，“ Using Stories with Scrum”），或本土开发的、故事驱动的敏捷过程。
The first thing you’ll notice on a story-driven project is that customers and users remain involved throughout the duration of the project. They are not expected (or allowed!) to disappear during the middle of the project. This is true whether the team will be using Extreme Programming (XP; see Appendix A, “An Overview of Extreme Programming,” for more information), an agile version of the Unified Process, an agile process like Scrum (see Chapter 15, “Using Stories with Scrum”), or a home-grown, story-driven agile process.
新软件的客户和预期用户应该计划在编写用户故事时扮演非常积极的角色，尤其是在使用 XP 的情况下。故事写作过程最好从考虑目标用户的类型开始系统。例如，如果您正在构建一个旅游预订网站，您可能有常旅客、假期计划者等用户类型。客户团队应尽可能多地包括这些用户类型的代表。但当它做不到时，用户角色建模可以提供帮助。（有关此主题的更多信息，请参阅第 3 章“用户角色建模”。）
The customers and intended users of the new software should plan on taking a very active role in writing the user stories, especially if using XP. The story writing process is best started by considering the types of users of the intended system. For example, if you are building a travel reservation website, you may have user types such as frequent fliers, vacation planners, and so on. The customer team should include representatives of as many of these user types as practical. But when it can’t, user role modeling can help. (For more on this topic see Chapter 3, “User Role Modeling.”)
客户为什么要写故事？
客户团队而不是开发人员编写用户故事有两个主要原因。首先，每个故事都必须用业务语言而不是技术术语来编写，以便客户团队可以优先考虑故事以包含在迭代和发布中。其次，作为主要的产品远见者，客户团队处于描述产品行为的最佳位置。
The customer team, rather than the developers, writes the user stories for two primary reasons. First, each story must be written in the language of the business, not in technical jargon, so that the customer team can prioritize the stories for inclusion into iterations and releases. Second, as the primary product visionaries, the customer team is in the best position to describe the behavior of the product.
项目的初始故事通常是在故事写作工作室中编写的，但故事可以在整个项目的任何时间编写。在故事写作工作坊中，每个人都尽可能多地集思广益。有了一组起始故事，开发人员估计每个故事的大小。
A project’s initial stories are often written in a story writing workshop, but stories can be written at any time throughout the project. During the story writing workshop, everyone brainstorms as many stories as possible. Armed with a starting set of stories, the developers estimate the size of each.
客户团队和开发人员协作选择迭代长度，可能从一到四个星期不等。相同的迭代长度将用于项目的持续时间。在每次迭代结束时，开发人员将负责为应用程序的某些子集交付完全可用的代码。客户团队在迭代期间保持高度参与，与开发人员讨论该迭代期间正在开发的故事。在迭代期间，客户团队还指定测试并与开发人员合作以自动化和运行测试。此外，客户团队确保项目不断朝着交付所需产品的方向发展。
Collaboratively, the customer team and developers select an iteration length, from perhaps one to four weeks. The same iteration length will be used for the duration of the project. By the end of each iteration the developers will be responsible for delivering fully usable code for some subset of the application. The customer team remains highly involved during the iteration, talking with the developers about the stories being developed during that iteration. During the iteration the customer team also specifies tests and works with the developers to automate and run tests. Additionally, the customer team makes sure the project is constantly moving toward delivery of the desired product.
一旦选择了迭代长度，开发人员将估计每次迭代他们能够完成多少工作。我们称之为速度。团队对速度的初步估计是错误的，因为无法提前知道速度。然而，我们可以使用初始估计来制定粗略的草图或发布计划，了解每次迭代中将发生什么工作以及需要多少次迭代。
Once an iteration length has been selected, the developers will estimate how much work they’ll be able to do per iteration. We call this velocity. The team’s first estimate of velocity will be wrong because there’s no way to know velocity in advance. However, we can use the initial estimate to make a rough sketch, or release plan, of what work will happen in each iteration and how many iterations will be needed.
为了计划发布，我们将故事分成不同的堆，每个堆代表一个迭代。每堆将包含一定数量的故事，这些故事的估计加起来不超过估计的速度。最高优先级的故事进入第一堆。当该堆已满时，下一个优先级最高的故事将进入第二堆（代表第二次迭代）。这一直持续到您要么制作了太多堆以致于没有时间进行该项目，要么直到这些堆代表了理想的产品新版本。（有关这些主题的更多信息，请参阅第 9 章“计划发布”和第 10 章“计划迭代”。）
To plan a release, we sort stories into various piles with each pile representing an iteration. Each pile will contain some number of stories, the estimates for which add up to no more than the estimated velocity. The highest-priority stories go into the first pile. When that pile is full, the next highest-priority stories go into a second pile (representing the second iteration). This continues until you’ve either made so many piles that you’re out of time for the project or until the piles represent a desirable new release of the product. (For more on these topics see Chapter 9, “Planning a Release,” and Chapter 10, “Planning an Iteration.”)
在每次迭代开始之前，客户团队可以对计划进行中期修正。随着迭代的完成，我们了解了开发团队的实际速度，并可以使用它来代替估计的速度。这意味着每堆故事可能需要通过添加或删除故事来调整。此外，有些故事会比预期的要容易得多，这意味着团队有时会希望在该迭代中获得额外的故事。但有些故事会比预期的更难，这意味着有些工作需要移到以后的迭代中或完全从发布中移出。
Prior to the start of each iteration the customer team can make mid-course corrections to the plan. As iterations are completed, we learn the development team’s actual velocity and can work with it instead of the estimated velocity. This means that each pile of stories may need to be adjusted by adding or removing stories. Also, some stories will turn out to be far easier than anticipated, which means the team will sometimes want to be given an additional story to do in that iteration. But some stories will be harder than anticipated, which means that some work will need to be moved into later iterations or out of the release altogether.
规划发布和迭代
Planning Releases and Iterations
一个版本由一个或多个迭代组成。发布计划是指确定预计时间线和所需功能集之间的平衡。迭代计划是指选择故事以包含在该迭代中。客户团队和开发人员都参与发布和迭代计划。
A release is made up of one or more iterations. Release planning refers to determining a balance between a projected timeline and a desired set of functionality. Iteration planning refers to selecting stories for inclusion in this iteration. The customer team and the developers are both involved in release and iteration planning.
要计划发布，客户团队首先要确定故事的优先级。在确定优先级时，他们会考虑：
To plan a release, the customer team starts by prioritizing the stories. While prioritizing they will want to consider:
- 该功能对广大用户或客户的需求
- The desirability of the feature to a broad base of users or customers
- 该功能对少数重要用户或客户的需求
- The desirability of the feature to a small number of important users or customers
- 故事相对于其他故事的凝聚力。例如，“缩小”故事本身可能不是高优先级，但可能会被视为高优先级，因为它是对“放大”的补充，后者是高优先级。
- The cohesiveness of the story in relation to other stories. For example, a “zoom out” story may not be high priority on its own but may be treated as such because it is complementary to “zoom in,” which is high priority.
开发人员对许多故事有不同的优先级。他们可能会建议根据故事的技术风险或与另一个故事的互补性来更改故事的优先级。客户团队听取他们的意见，然后以最大化交付给组织的价值的方式对故事进行优先排序。
The developers have different priorities for many of the stories. They may suggest that the priority of a story be changed based on its technical risk or because it is complementary to another story. The customer team listens to their opinions but then prioritizes stories in the manner that maximizes the value delivered to the organization.
如果不考虑成本，就不能确定故事的优先级。去年夏天我优先考虑的度假胜地是塔希提岛，直到我考虑了它的成本。在那时候其他位置的优先级上升。考虑到优先级的是每个故事的成本。一个故事的成本是开发商给它的估计。每个故事都被分配了一个以故事点为单位的估计值，它表示故事相对于其他故事的大小和复杂性。因此，估计为四个故事点的故事所用的时间预计是估计为两个故事点的故事所用时间的两倍。
Stories cannot be prioritized without considering their costs. My priority for a vacation spot last summer was Tahiti until I considered its cost. At that point other locations moved up in priority. Factored into the prioritization is the cost of each story. The cost of a story is the estimate given to it by the developers. Each story is assigned an estimate in story points, which indicates the size and complexity of the story relative to other stories. So, a story estimated at four story points is expected to take twice as long as a story estimated at two story points.
发布计划是通过将故事分配给发布中的迭代来构建的。开发人员陈述了他们的预期速度，即他们认为每次迭代将完成的故事点数。然后客户将故事分配给迭代，确保分配给任何一个迭代的故事点数不超过预期的团队速度。
The release plan is built by assigning stories to the iterations in the release. The developers state their expected velocity, which is the number of story points they think they will complete per iteration. The customer then allocates stories to iterations, making sure that the number of story points assigned to any one iteration does not exceed the expected team velocity.
例如，假设表 1.1列出了项目中的所有故事，并且它们按优先级降序排列。该团队估计每次迭代的速度为 13 个故事点。故事将分配给迭代，如表 1.2所示。
As an example, suppose that Table 1.1 lists all the stories in your project and they are sorted in order of descending priority. The team estimates a velocity of thirteen story points per iteration. Stories would be allocated to iterations as shown in Table 1.2.
表 1.1。 示例故事及其成本。
Table 1.1. Sample stories and their costs.
因为团队期望速度为 13，所以不能计划迭代中包含超过 13 个故事点。这意味着第二次和第三次迭代计划只有十二个故事点。别担心——估计很少精确到足以影响这种差异的程度，如果开发人员的进度比计划快，他们会要求再提供一两个小故事。请注意，对于第三次迭代，客户团队实际上选择了在优先级更高的 Story I 中包含 Story J。这是因为 Story I 在五个故事点上实际上太大而无法包含在第三次迭代中。
Because the team expects a velocity of thirteen, no iteration can be planned to have more than thirteen story points in it. This means that the second and third iterations are planned to have only twelve story points. Don’t worry about it—estimation is rarely precise enough for this difference to matter, and if the developers go faster than planned they’ll ask for another small story or two. Notice that for the third iteration the customer team has actually chosen to include Story J over the higher priority Story I. This is because Story I, at five story points, is actually too large to include in the third iteration.
表 1.2。 表 1.1中故事的发布计划。
Table 1.2. A release plan for the stories of Table 1.1.
暂时跳过一个大故事并在迭代中放置一个小故事的替代方法是将大故事分成两个故事。假设五点故事 I 可以分为故事 Y（三点）和故事 Z（两点）。故事 Y 包含旧故事 I 的最重要部分，现在可以放入第三次迭代，如表 1.3所示。有关如何以及何时拆分故事的建议，请参阅第 2 章“编写故事”和第 7 章“好故事指南”。
An alternative to temporarily skipping a large story and putting a smaller one in its place in an iteration is to split the large story into two stories. Suppose that the five-point Story I could have been split into Story Y (three points) and Story Z (two points). Story Y contains the most important parts of the old Story I and can now fit in the third iteration, as shown in Table 1.3. For advice on how and when to split stories see Chapter 2, “Writing Stories,” and Chapter 7, “Guidelines for Good Stories.”
表 1.3。 拆分故事以创建更好的发布计划。
Table 1.3. Splitting a story to create a better release plan.
什么是验收测试？
What Are Acceptance Tests?
验收测试是验证故事的开发过程，以便每个故事都完全按照客户团队期望的方式工作。一旦迭代开始，开发人员开始编码，客户团队开始指定测试。根据客户团队成员的技术熟练程度，这可能意味着从在故事卡背面编写测试到将测试放入自动化测试工具的任何事情。客户团队中应包括一名敬业且熟练的测试人员，以完成这些任务的更多技术性。
Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work. Once an iteration begins, the developers start coding and the customer team starts specifying tests. Depending on the technical proficiency of customer team members, this may mean anything from writing tests on the back of the story card to putting the tests into an automated testing tool. A dedicated and skilled tester should be included on the customer team for the more technical of these tasks.
测试应该在迭代中尽可能早地编写（如果您愿意稍微猜测一下迭代中的内容，甚至可以稍微早于迭代）即将到来的迭代）。尽早编写测试非常有帮助，因为客户团队的更多假设和期望会更早地传达给开发人员。例如，假设您写了这样一个故事：“用户可以使用信用卡为购物车中的商品付款。” 然后，您在该故事卡的背面写下这些简单的测试：
Tests should be written as early in an iteration as possible (or even slightly before the iteration if you’re comfortable taking a slight guess at what will be in the upcoming iteration). Writing tests early is extremely helpful because more of the customer team’s assumptions and expectations are communicated earlier to the developers. For example, suppose you write the story “A user can pay for the items in her shopping cart with a credit card.” You then write these simple tests on the back of that story card:
- 使用 Visa、MasterCard 和 American Express（通过）进行测试。
- Test with Visa, MasterCard and American Express (pass).
- 用 Diner's Club 测试（失败）。
- Test with Diner’s Club (fail).
- 使用 Visa 借记卡进行测试（通过）。
- Test with a Visa debit card (pass).
- 使用卡片背面的好、坏和缺失卡 ID 号进行测试。
- Test with good, bad and missing card ID numbers from the back of the card.
- 用过期的卡测试。
- Test with expired cards.
- 使用不同的购买金额（包括超过卡限额的金额）进行测试。
- Test with different purchase amounts (including one over the card’s limit).
这些测试反映了系统将处理 Visa、MasterCard 和 American Express 并且不允许使用其他卡进行购买的预期。通过尽早将这些测试交给程序员，客户团队不仅表达了他们的期望，他们还可能提醒程序员她忘记的情况。例如，她可能忘记考虑过期的卡。在她开始编程之前将其记为卡背面的测试将节省她的时间。有关为故事编写验收测试的更多信息，请参阅第 6 章“验收测试用户故事”。
These tests capture the expectations that the system will handle Visa, MasterCard and American Express and will not allow purchases with other cards. By giving these tests to the programmer early, the customer team has not only stated their expectations, they may also have reminded the programmer of a situation she had otherwise forgotten. For example, she may have forgotten to consider expired cards. Noting it as a test on the back of the card before she starts programming will save her time. For more on writing acceptance tests for stories see Chapter 6, “Acceptance Testing User Stories.”
为什么要改变？
Why Change?
此时你可能会问为什么要改变？为什么要写故事卡并进行所有这些对话？为什么不继续编写需求文档或用例呢？与其他方法相比，用户故事具有许多优势。第 13 章“为什么要使用用户故事？”中提供了更多详细信息，其中一些原因是：
At this point you may be asking why change? Why write story cards and hold all these conversatons? Why not just continue to write requirements documents or use cases? User stories offer a number of advantages over alternative approaches. More details are provided in Chapter 13, “Why User Stories?”, but some of the reasons are:
- 用户故事强调口头而非书面交流。
- User stories emphasize verbal rather than written communication.
- 您和开发人员都可以理解用户故事。
- User stories are comprehensible by both you and the developers.
- 用户故事的大小适合规划。
- User stories are the right size for planning.
- 用户故事适用于迭代开发。
- User stories work for iterative development.
- 用户故事鼓励推迟细节，直到你对你真正需要的东西有最好的了解。
- User stories encourage deferring detail until you have the best understanding you are going to have about what you really need.
因为用户故事将重点从写作转移到谈话上，所以重要的决定不会记录在不太可能被阅读的文档中。相反，关于故事的重要方面被捕获在自动验收测试中并经常运行。此外，我们避免使用带有以下语句的晦涩的书面文档：
Because user stories shift emphasis toward talking and away from writing, important decisions are not captured in documents that are unlikely to be read. Instead, important aspects about stories are captured in automated acceptance tests and run frequently. Additionally, we avoid obtuse written documents with statements like:
系统必须存储地址和公司电话号码或手机号码。
The system must store an address and business phone number or mobile phone number.
那是什么意思？这可能意味着系统必须存储以下之一：
What does that mean? It could mean that the system must store one of these:
（地址和公司电话）或手机
地址和（公司电话或手机）
(Address and business phone) or mobile phone
Address and (business phone or mobile phone)
因为用户故事没有技术术语（记住，它们是由客户团队编写的），所以开发人员和客户团队都可以理解它们。
Because user stories are free of technical jargon (remember, the customer team writes them), they are comprehensible by both the developers as well as the customer team.
每个用户故事代表一个独立的功能；也就是说，用户在单一设置中可能会做的事情。这使得用户故事适合作为规划工具。与评估遗漏一个或多个“系统应……”语句的影响相比，您可以更好地评估在不同版本之间转移故事的价值。
Each user story represents a discrete piece of functionality; that is, something a user would be likely to do in a single setting. This makes user stories appropriate as a planning tool. You can assess the value of shifting stories between releases far better than you can assess the impact of leaving out one or more “The system shall…” statements.
迭代过程是通过连续改进取得进展的过程。开发团队在了解系统在某些（可能是许多）领域不完整或薄弱的情况下进行了第一次切割。然后，他们依次改进这些区域，直到产品令人满意为止。每次迭代都会通过添加更多细节来改进软件。故事很适合迭代开发，因为它也可以迭代故事。对于您最终想要但现在并不重要的功能，您可以先写一个大故事（史诗）。当您准备好将该故事添加到系统中时，您可以通过撕掉史诗并将其替换为更易于使用的较小故事来对其进行完善。
An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. They then successively refine those areas until the product is satisfactory. With each iteration the software is improved through the addition of greater detail. Stories work well for iterative development because it is also possible to iterate over the stories. For a feature that you want eventually but that isn’t important right now, you can first write a large story (an epic). When you’re ready to add that story into the system you can refine it by ripping up the epic and replacing it with smaller stories that will be easier to work with.
正是这种迭代故事集的能力让故事鼓励推迟细节。因为我们今天可以写一个占位符史诗，所以在接近开发这些部分的时候，不需要写关于系统部分的故事。推迟细节很重要，因为它允许我们在确定需要该功能之前不要花时间考虑新功能。故事阻止我们假装我们可以提前知道和写下一切。相反，他们鼓励基于客户团队和开发人员之间的讨论迭代改进软件的过程。
It is this ability to iterate over a story set that allows stories to encourage the deferring of detail. Because we can write a placeholder epic today, there is no need to write stories about parts of a system until close to when those parts will be developed. Deferring detail is important because it allows us to not spend time thinking about a new feature until we are positive the feature is needed. Stories discourage us from pretending we can know and write everything in advance. Instead they encourage a process whereby software is iteratively refined based on discussions between the customer team and the developers.
概括
Summary
- 故事卡包含对用户或客户有价值的功能的简短描述。
- A story card contains a short description of user- or customer-valued functionality.
- 故事卡是故事的可见部分，但重要的部分是客户和开发人员之间关于故事的对话。
- A story card is the visible part of a story, but the important parts are the conversations between the customer and developers about the story.
- 客户团队包括确保软件满足其预期用户需求的人员。这可能包括测试人员、产品经理、真实用户和交互设计师。
- The customer team includes those who ensure that the software will meet the needs of its intended users. This may include testers, a product manager, real users, and interaction designers.
- 客户团队编写故事卡是因为他们处于表达所需功能的最佳位置，并且因为他们以后必须能够与开发人员一起制定故事细节并确定故事的优先级。
- The customer team writes the story cards because they are in the best position to express the desired features and because they must later be able to work out story details with the developers and to prioritize the stories.
- 故事根据它们对组织的价值进行优先排序。
- Stories are prioritized based on their value to the organization.
- 通过将故事放入迭代中来计划发布和迭代。
- Releases and iterations are planned by placing stories into iterations.
- 速度是开发人员在一次迭代中可以完成的工作量。
- Velocity is the amount of work the developers can complete in an iteration.
- 放置在迭代中的故事的估计总和不能超过开发人员为该迭代预测的速度。
- The sum of the estimates of the stories placed in an iteration cannot exceed the velocity the developers forecast for that iteration.
- 如果故事不适合迭代，您可以将故事拆分为两个或更多更小的故事。
- If a story won’t fit in an iteration, you can split the story into two or more smaller stories.
- 验收测试验证故事的开发是否具有客户团队在编写故事时所考虑的功能。
- Acceptance tests validate that a story has been developed with the functionality the customer team had in mind when they wrote the story.
- 用户故事值得使用，因为它们强调口头交流，可以被你和开发人员平等地理解，可以用于规划迭代，在迭代开发过程中工作得很好，并且因为它们鼓励推迟细节。
- User stories are worth using because they emphasize verbal communication, can be understood equally by you and the developers, can be used for planning iterations, work well within an iterative development process, and because they encourage the deferring of detail.
问题
Questions
1.1 用户故事的三个部分是什么？
1.1 What are the three parts of a user story?
1.2 客户团队中有哪些人？
1.2 Who is on the customer team?
1.3 以下哪个不是好故事？为什么？
1.3 Which of the following are not good stories? Why?
一种。用户可以在 Windows XP 和 Linux 上运行该系统。
a. The user can run the system on Windows XP and Linux.
b. 所有图形和图表都将使用第三方库完成。
b. All graphing and charting will be done using a third-party library.
C。用户最多可以撤消五十个命令。
c. The user can undo up to fifty commands.
d. 该软件将于 6 月 30 日发布。
d. The software will be released by June 30.
e. 该软件将用 Java 编写。
e. The software will be written in Java.
F。用户可以从下拉列表中选择她的国家。
f. The user can select her country from a drop-down list.
G。系统将使用 Log4J 将所有错误消息记录到一个文件中。
g. The system will use Log4J to log all error messages to a file.
H。如果用户在 15 分钟内没有保存工作，系统将提示她保存工作。
h. The user will be prompted to save her work if she hasn’t saved it for 15 minutes.
一世。用户可以选择“导出为 XML”功能。
i. The user can select an “Export to XML” feature.
j. 用户可以将数据导出为 XML。
j. The user can export data to XML.
1.4 需求对话比需求文档有什么优势？
1.4 What advantages do requirements conversations have over requirements documents?
1.5 为什么要在故事卡背面写测试？
1.5 Why would you want to write tests on the back of a story card?
第 2 章写故事
Chapter 2. Writing Stories
在本章中，我们将注意力转向编写故事。为了创造好故事，我们关注六个属性。一个好的故事是：
In this chapter we turn our attention to writing the stories. To create good stories we focus on six attributes. A good story is:
- 独立的
- Independent
- 面议
- Negotiable
- 对用户或客户有价值
- Valuable to users or customers
- 可估价
- Estimatable
- 小的
- Small
- 可测试
- Testable
Bill Wake，Extreme Programming Explored and Refactoring Workbook的作者，建议使用首字母缩略词 INVEST 来表示这六个属性 (Wake 2003a)。
Bill Wake, author of Extreme Programming Explored and Refactoring Workbook, has suggested the acronym INVEST for these six attributes (Wake 2003a).
独立的
Independent
应尽可能注意避免在故事之间引入依赖关系。故事之间的依赖关系会导致优先级排序和计划问题。例如，假设客户选择了一个依赖于低优先级故事的故事作为高优先级故事。故事之间的依赖性也会使估计变得比需要的更难。例如，假设我们在 BigMoneyJobs 网站上工作，需要撰写有关公司如何为他们发布到我们网站上的职位空缺付款的故事。我们可以写这些故事：
As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is low priority. Dependencies between stories can also make estimation much harder than it needs to be. For example, suppose we are working on the BigMoneyJobs website and need to write stories for how companies can pay for the job openings they post to our site. We could write these stories:
1. 公司可以使用 Visa 卡支付职位发布费用。
1. A company can pay for a job posting with a Visa card.
2. 公司可以使用万事达卡支付职位发布费用。
2. A company can pay for a job posting with a MasterCard.
3. A company can pay for a job posting with an American Express card.
假设开发人员估计需要三天时间来支持第一种信用卡类型（不管它是什么），然后为第二种和第三种各花一天时间。对于诸如此类高度依赖的故事，您不知道为每个故事提供多少估算值——应该为哪个故事提供三天估算值？
Suppose the developers estimate that it will take three days to support the first credit card type (regardless of which it is) and then one day each for the second and third. With highly dependent stories such as these you don’t know what estimate to give each story—which story should be given the three day estimate?
当出现这种类型的依赖时，有两种解决方法：
When presented with this type of dependency, there are two ways around it:
- 将相关故事合并为一个更大但独立的故事
- Combine the dependent stories into one larger but independent story
- 寻找一种不同的方式来分解故事
- Find a different way of splitting the stories
在这种情况下，将关于不同信用卡类型的故事组合成一个大故事（“一家公司可以用信用卡支付职位发布费用”）效果很好，因为组合后的故事只有五天。如果组合的故事比这长得多，更好的方法通常是找到一个不同的维度来拆分故事。如果对这些故事的估计时间更长，那么另一种拆分方式将是：
Combining the stories about the different credit card types into a single large story (“A company can pay for a job posting with a credit card”) works well in this case because the combined story is only five days long. If the combined story is much longer than that, a better approach is usually to find a different dimension along which to split the stories. If the estimates for these stories had been longer, then an alternative split would be:
1. 一个客户可以使用一种信用卡支付。
1. A customer can pay with one type of credit card.
2. 客户可以使用两种额外的信用卡付款。
2. A customer can pay with two additional types of credit cards.
如果你不想合并这些故事，也找不到拆分它们的好方法，你总是可以采取简单的方法，在卡片上放两个估计值：一个估计故事是否先于另一个故事完成，一个如果之后完成，估计会更低。
If you don’t want to combine the stories and can’t find a good way to split them, you can always take the simple approach of putting two estimates on the card: one estimate if the story is done before the other story, a lower estimate if it is done after.
面议
Negotiable
故事是可以商量的。它们不是软件必须执行的书面合同或要求。故事卡是对功能的简短描述，其细节将在客户和开发团队之间的对话中协商。因为故事卡是进行对话的提醒，而不是完全详细的需求本身，所以它们不需要包括所有相关细节。但是，如果在编写故事时已知一些重要细节，则应将它们作为注释包含在故事卡中，如故事卡 2.1所示。挑战在于学习包含足够的细节。
Stories are negotiable. They are not written contracts or requirements that the software must implement. Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team. Because story cards are reminders to have a conversation rather than fully detailed requirements themselves, they do not need to include all relevant details. However, if at the time the story is written some important details are known, they should be included as annotations to the story card, as shown in Story Card 2.1. The challenge comes in learning to include just enough detail.
Story Card 2.1运作良好，因为它为将要谈论故事的开发人员和客户提供了适量的信息。当开发人员开始编写这个故事时，系统会提醒她已经决定接受三张主卡，她可以询问客户是否已决定接受 Discover 卡。卡片上的注释可帮助开发人员和客户从之前中断的地方继续对话。理想情况下，无论恢复对话的是同一开发人员还是客户，都可以如此轻松地恢复对话。在向故事添加细节时使用此作为指南。
Story Card 2.1 works well because it provides the right amount of information to the developer and customer who will talk about the story. When a developer starts to code this story, she will be reminded that a decision has already been made to accept the three main cards and she can ask the customer if a decision has been made about accepting Discover cards. The notes on the card help a developer and the customer to resume a conversation where it left off previously. Ideally, the conversation can be resumed this easily regardless of whether it is the same developer and customer who resume the conversation. Use this as a guideline when adding detail to stories.
Story Card 2.1. A story card with notes providing additional detail.
另一方面，考虑一个注释过多的故事，如Story Card 2.2中所示。这个故事有太多的细节（“收集卡的到期月份和日期”）并且还结合了可能应该是一个单独的故事（“系统可以存储卡号以备将来使用”）。
On the other hand, consider a story that is annotated with too many notes, as shown in Story Card 2.2. This story has too much detail (“Collect the expiration month and date of the card”) and also combines what should probably be a separate story (“The system can store a card number for future use”).
故事卡 2.2。一张有太多细节的故事卡片。
Story Card 2.2. A story card with too much detail.
使用Story Card 2.2这样的故事非常困难。大多数这类故事的读者会错误地将额外的细节与额外的精确联系起来。然而，在许多情况下，过早指定细节只会增加工作量。例如，如果两个开发人员讨论并估计一个简单的故事“一家公司可以用信用卡支付职位发布费用”，他们不会忘记他们的讨论有些抽象。缺少太多细节他们错误地认为他们的讨论是确定的或他们的估计是准确的。然而，当故事卡 2.2中添加了尽可能多的细节时，关于故事的讨论更有可能变得具体和真实。这可能会导致错误地认为故事卡反映了所有细节，并且没有必要进一步与客户讨论故事。
Working with stories like Story Card 2.2 is very difficult. Most readers of this type of story will mistakenly associate the extra detail with extra precision. However, in many cases specifying details too soon just creates more work. For example, if two developers discuss and estimate a story that says simply “a company can pay for a job posting with a credit card” they will not forget that their discussion is somewhat abstract. There are too many missing details for them to mistakenly view their discussion as definitive or their estimate as accurate. However, when as much detail is added as in Story Card 2.2, discussions about the story are much more likely to feel concrete and real. This can lead to the mistaken belief that the story cards reflect all the details and that there’s no further need to discuss the story with the customer.
如果我们将故事卡视为开发人员和客户进行对话的提醒，那么将故事卡视为包含：
If we think about the story card as a reminder for the developer and customer to have a conversation, then it is useful to think of the story card as containing:
- 一两个短语作为保持对话的提醒
- a phrase or two that act as reminders to hold the conversation
- 记录谈话中要解决的问题
- notes about issues to be resolved during the conversation
通过对话已经确定的细节成为测试。如果使用记事卡或在任何正在使用的电子系统中，可以在故事卡的背面注明测试。故事卡 2.3和故事卡 2.4展示了如何将故事卡 2.2的多余细节转化为测试，只留下对话的注释作为故事卡正面的一部分。这样，故事卡片的正面包含故事和关于开放式问题的注释，而卡片的背面包含故事的详细信息，以测试的形式出现，以证明它是否按预期工作。
Details that have already been determined through conversations become tests. Tests can be noted on the back of the story card if using note cards or in whatever electronic system is being used. Story Card 2.3 and Story Card 2.4 show how the excess detail of Story Card 2.2 can be turned into tests, leaving just notes for the conversation as part of the front of the story card. In this way, the front of a story card contains the story and notes about open questions while the back of the card contains details about the story in the form of tests that will prove whether or not it works as expected.
故事卡 2.3。修改后的故事卡片正面，只有故事和要讨论的问题。
Story Card 2.3. The revised front of a story card with only the story and questions to be discussed.
对购买者或用户有价值
Valuable to Purchasers or Users
很容易说出“每个故事都必须被用户重视”这样的话。但那是错误的。许多项目包含用户不重视的故事。请牢记用户（使用软件的人）和购买者（购买软件的人）之间的区别，假设一个开发团队正在构建将在大型用户群（可能是一家公司的 5,000 台计算机）中部署的软件。此类产品的购买者可能非常担心 5,000 台计算机中的每台计算机都使用相同的软件配置。这可能会导致类似“所有配置信息都从中央位置读取”这样的故事。用户不关心配置信息存储在哪里，但购买者可能关心。
It is tempting to say something along the lines of “Each story must be valued by the users.” But that would be wrong. Many projects include stories that are not valued by users. Keeping in mind the distinction between user (someone who uses the software) and purchaser (someone who purchases the software), suppose a development team is building software that will be deployed across a large user base, perhaps 5,000 computers in a single company. The purchaser of a product like that may be very concerned that each of the 5,000 computers is using the same configuration for the software. This may lead to a story like “All configuration information is read from a central location.” Users don’t care where configuration information is stored but purchasers might.
故事卡 2.4。暗示测试用例的细节与故事本身是分开的。它们显示在故事卡的背面。
Story Card 2.4. Details that imply test cases are separated from the story itself. Here they are shown on the back of the story card.
同样，考虑购买产品的购买者可能会看重以下故事，但实际用户不会看重：
Similarly, stories like the following might be valued by purchasers contemplating buying the product but would not be valued by actual users:
- 在整个开发过程中，开发团队将制作适合 ISO 9001 审核的文档。
- Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit.
- 开发团队将根据 CMM Level 3 生产软件。
- The development team will produce the software in accordance with CMM Level 3.
您要避免的是只被开发人员看重的故事。例如，避免这样的故事：
What you want to avoid are stories that are only valued by developers. For example, avoid stories like these:
- 所有与数据库的连接都通过一个连接池。
- All connections to the database are through a connection pool.
- 所有错误处理和日志记录都是通过一组通用类完成的。
- All error handling and logging is done through a set of common classes.
如所写，这些故事的重点是技术和对程序员的优势。这些故事背后的想法很可能是好的，但它们应该被写下来，以便对客户或用户的好处是显而易见的。这将允许客户智能地将这些故事按优先顺序排列到开发计划中。这些故事的更好变体可能如下：
As written, these stories are focused on the technology and the advantages to the programmers. It is very possible that the ideas behind these stories are good ones but they should instead be written so that the benefits to the customers or the user are apparent. This will allow the customer to intelligently prioritize these stories into the development schedule. Better variations of these stories could be the following:
- 最多五十个用户应该能够使用具有五用户数据库许可证的应用程序。
- Up to fifty users should be able to use the application with a five-user database license.
- 所有错误都呈现给用户并以一致的方式记录。
- All errors are presented to the user and logged in a consistent manner.
以完全相同的方式值得尝试将用户界面假设排除在故事之外，将技术假设排除在故事之外也是值得的。例如，上面修改后的故事已经删除了连接池和一组错误处理类的隐式使用。
In exactly the same way it is worth attempting to keep user interface assumptions out of stories, it is also worth keeping technology assumptions out of stories. For example, the revised stories above have removed the implicit use of a connection pool and a set of error handling classes.
确保每个故事对客户或用户有价值的最佳方法是让客户编写故事。客户最初通常对此感到不自在——可能是因为开发人员训练他们将他们编写的所有内容都视为以后可以对他们不利的东西。（“好吧，需求文档没有这么说……”）大多数客户一旦接受了故事卡是提醒稍后再谈的概念，而不是正式的承诺或特定功能的描述，就开始自己编写故事。
The best way to ensure that each story is valuable to the customer or users is to have the customer write the stories. Customers are often uncomfortable with this initially—probably because developers have trained them to think of everything they write as something that can be held against them later. (“Well, the requirements document didn’t say that…”) Most customers begin writing stories themselves once they become comfortable with the concept that story cards are reminders to talk later rather than formal commitments or descriptions of specific functionality.
可估价
Estimatable
对于开发人员而言，重要的是能够估计（或至少猜测）故事的大小或将故事转化为工作代码所需的时间。一个故事可能无法估计的原因有以下三个：
It is important for developers to be able to estimate (or at least take a guess at) the size of a story or the amount of time it will take to turn a story into working code. There are three common reasons why a story may not be estimatable:
1. 开发人员缺乏领域知识。
1. Developers lack domain knowledge.
2. 开发人员缺乏技术知识。
2. Developers lack technical knowledge.
3.故事太大。
3. The story is too big.
首先，开发人员可能缺乏领域知识。如果开发人员不理解所写的故事，他们应该与编写故事的客户讨论。同样，没有必要了解故事的所有细节，但开发人员需要对故事有一个大致的了解。
First, the developers may lack domain knowledge. If the developers do not understand a story as it is written, they should discuss it with the customer who wrote the story. Again, it’s not necessary to understand all the details about a story, but the developers need to have a general understanding of the story.
其次，一个故事可能无法估计，因为开发者不了解所涉及的技术。例如，在一个 Java 项目中，我们被要求为系统提供一个 CORBA 接口。团队中没有人这样做过，因此无法估计任务。在这种情况下，解决方案是派一名或多名开发人员进行极限编程称为spike的活动，这是了解应用程序某个区域的简短实验。在峰值期间，开发人员学到的知识足以让他们估计任务。尖峰本身总是被赋予定义的最大时间量（称为timebox），这使我们能够估计尖峰。通过这种方式，一个不可估量的故事变成了两个故事：一个快速收集信息的故事，然后一个故事做真正的工作。
Second, a story may not be estimatable because the developers do not understand the technology involved. For example, on one Java project we were asked to provide a CORBA interface into the system. No one on the team had done that so there was no way to estimate the task. The solution in this case is to send one or more developers on what Extreme Programming calls a spike, which is a brief experiment to learn about an area of the application. During the spike the developers learn just enough that they can estimate the task. The spike itself is always given a defined maximum amount of time (called a timebox), which allows us to estimate the spike. In this way an unestimatable story turns into two stories: a quick spike to gather information and then a story to do the real work.
最后，如果故事太大，开发人员可能无法估算故事。例如，对于 BigMoneyJobs 网站，“A Job Seeker can find a job”的故事太大了。为了对其进行估算，开发人员需要将其分解为更小的组成故事。
Finally, the developers may not be able to estimate a story if it is too big. For example, for the BigMoneyJobs website, the story “A Job Seeker can find a job” is too large. In order to estimate it the developers will need to disaggregate it into smaller, constituent stories.
缺乏领域知识
作为需要更多领域知识的一个例子，我们正在建立一个用于慢性病长期医疗的网站。客户（一位高素质的护士）写了一个故事，说“新用户接受了糖尿病筛查”。开发人员不确定这意味着什么，它可能涵盖了从简单的网络问卷调查到实际向新用户发送一些内容以进行家庭身体检查的范围，就像该公司针对哮喘患者的产品所做的那样。开发人员与客户会面，发现她正在考虑一个简单的 Web 表单，其中包含一些问题。
As an example of needing more domain knowledge, we were building a website for long-term medical care of chronic conditions. The customer (a highly qualified nurse) wrote a story saying “New users are given a diabetic screening.” The developers weren’t sure what that meant and it could have run the gamut from a simple web questionnaire to actually sending something to new users for an at-home physical screening, as was done for the company’s product for asthma patients. The developers got together with the customer and found out that she was thinking of a simple web form with a handful of questions.
尽管它们太大而无法可靠地估计，但有时编写诸如“求职者可以找到工作”之类的史诗是有用的，因为它们可以作为占位符或提醒系统中需要讨论的大部分内容。如果您有意识地决定暂时掩盖系统的大部分内容，请考虑编写一两部涵盖这些部分的史诗。史诗可以分配一个大的，从稀薄的空气中提取的估计。
Even though they are too big to estimate reliably, it is sometimes useful to write epics such as “A Job Seeker can find a job” because they serve as placeholders or reminders about big parts of a system that need to be discussed. If you are making a conscious decision to temporarily gloss over large parts of a system, then consider writing an epic or two that cover those parts. The epic can be assigned a large, pulled–from–thin–air estimate.
小的
Small
就像寻找舒适床的金发姑娘一样，有些故事可能太大，有些可能太小，有些则恰到好处。故事大小确实很重要，因为如果故事太大或太小，您就无法在计划中使用它们。史诗很难处理，因为它们经常包含多个故事。例如，在旅游预订系统中，“用户可以计划假期”是一个史诗。计划假期是旅行预订系统的重要功能，但其中涉及许多任务。史诗应该分成更小的故事。故事大小是否合适的最终决定取决于团队、团队的能力和使用的技术。
Like Goldilocks in search of a comfortable bed, some stories can be too big, some can be too small, and some can be just right. Story size does matter because if stories are too large or too small you cannot use them in planning. Epics are difficult to work with because they frequently contain multiple stories. For example, in a travel reservation system, “A user can plan a vacation” is an epic. Planning a vacation is important functionality for a travel reservation system but there are many tasks involved in doing so. The epic should be split into smaller stories. The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.
拆分故事
Splitting Stories
史诗通常属于以下两类之一：
Epics typically fall into one of two categories:
- 化合物的故事
- The compound story
- 复杂的故事
- The complex story
复合故事是由多个较短的故事组成的史诗。例如，BigMoneyJobs 系统可能包含故事“用户可以发布她的简历”。在系统的初始规划期间，这个故事可能是合适的。但是当开发人员与客户交谈时，他们发现“发布她的简历”实际上意味着：
A compound story is an epic that comprises multiple shorter stories. For example, the BigMoneyJobs system may include the story “A user can post her resume.” During the initial planning of the system this story may be appropriate. But when the developers talk to the customer, they find out that “post her resume” actually means:
- 简历可以包括教育、以前的工作、薪资历史、出版物、演示、社区服务和目标
- that a resume can include education, prior jobs, salary history, publications, presentations, community service, and an objective
- 用户可以将简历标记为无效
- that users can mark resumes as inactive
- 用户可以有多个简历
- that users can have multiple resumes
- 用户可以编辑简历
- that users can edit resumes
- 用户可以删除简历
- that users can delete resumes
根据这些开发需要多长时间，每个都可能成为自己独特的故事。然而，这可能只会让一部史诗在相反的方向上走得太远，把它变成一系列太小的故事。例如，根据使用的技术以及团队的规模和技能，像这样的故事通常会太小：
Depending on how long these will take to develop, each could become its own unique story. However, that may just take an epic and go too far in the opposite direction, turning it into a series of stories that are too small. For example, depending on the technologies in use and the size and skill of the team, stories like these will generally be too small:
- 求职者可以在简历上输入每个社区服务条目的日期。
- A Job Seeker can enter a date for each community service entry on a resume.
- 求职者可以编辑简历上每个社区服务条目的日期。
- A Job Seeker can edit the date for each community service entry on a resume.
- 求职者可以在简历中输入每个先前工作的日期范围。
- A Job Seeker can enter a date range for each prior job on a resume.
- 求职者可以编辑简历上每个先前工作的日期范围。
- A Job Seeker can edit the date range for each prior job on a resume.
通常，更好的解决方案是按如下方式对较小的故事进行分组：
Generally, a better solution is to group the smaller stories as follows:
- 用户可以创建简历，其中包括教育背景、之前的工作、薪资历史、出版物、演示文稿、社区服务和目标。
- A user can create resumes, which include education, prior jobs, salary history, publications, presentations, community service, and an objective.
- 用户可以编辑简历。
- A user can edit a resume.
- 用户可以删除简历。
- A user can delete a resume.
- 一个用户可以有多份简历。
- A user can have multiple resumes.
- 用户可以激活和停用简历。
- A user can activate and inactivate resumes.
通常有许多方法可以分解复合故事。前面的分解是按照常用的创建、编辑和删除行进行的。如果创建的故事足够小以至于可以作为一个故事保留，则此方法效果很好。另一种方法是沿着数据的边界分解。为此，请将简历的每个组成部分视为单独添加和编辑。这导致了完全不同的分解：
There are normally many ways to disaggregate a compound story. The preceding disaggregation is along the lines of create, edit, and delete, which is commonly used. This works well if the create story is small enough that it can be left as one story. An alternative is to disaggregate along the boundaries of the data. To do this, think of each component of a resume as being added and edited individually. This leads to a completely different disaggregation:
- 用户可以添加和编辑教育信息。
- A user can add and edit education information.
- 用户可以添加和编辑作业历史信息。
- A user can add and edit job history information.
- 用户可以添加和编辑工资历史信息。
- A user can add and edit salary history information.
- 用户可以添加和编辑发布。
- A user can add and edit publications.
- 用户可以添加和编辑演示文稿。
- A user can add and edit presentations.
- 用户可以添加和编辑社区服务。
- A user can add and edit community service.
- 用户可以添加和编辑目标。
- A user can add and edit an objective.
等等。
And so on.
与复合故事不同，复杂故事是一个用户故事，它本质上很大，不能轻易分解成一组组成故事。如果一个故事因其相关的不确定性而变得复杂，您可能希望将该故事分成两个故事：一个调查故事和一个开发新功能的故事。例如，假设给开发人员这样的故事“一家公司可以用信用卡支付职位发布费用”，但之前没有开发人员进行过信用卡处理。他们可能会选择这样拆分故事：
Unlike the compound story, the complex story is a user story that is inherently large and cannot easily be disaggregated into a set of constituent stories. If a story is complex because of uncertainty associated with it, you may want to split the story into two stories: one investigative and one developing the new feature. For example, suppose the developers are given the story “A company can pay for a job posting with a credit card” but none of the developers has ever done credit card processing before. They may choose to split the stories like this:
- 通过网络调查信用卡处理。
- Investigate credit card processing over the web.
- 用户可以使用信用卡支付。
- A user can pay with a credit card.
在这种情况下，第一个故事会让一个或多个开发人员大吃一惊。当以这种方式拆分复杂的故事时，请始终围绕调查故事或尖峰定义时间框。即使不能以任何合理的准确度估计故事，仍然可以定义将花费在学习上的最大时间量。
In this case the first story will send one or more developers on a spike. When complex stories are split in this way, always define a timebox around the investigative story, or spike. Even if the story cannot be estimated with any reasonable accuracy, it is still possible to define the maximum amount of time that will be spent learning.
在开发新算法或扩展已知算法时，复杂的故事也很常见。一家生物技术公司的一个团队有一个添加新扩展的故事到称为期望最大化的标准统计方法。复杂的故事被改写为两个故事：第一个研究和确定扩展期望最大化的可行性；第二个是将该功能添加到产品中。在这种情况下，很难估计研究故事需要多长时间。
Complex stories are also common when developing new or extending known algorithms. One team in a biotech company had a story to add novel extensions to a standard statistical approach called expectation maximization. The complex story was rewritten as two stories: the first to research and determine the feasibility of extending expectation maximization; the second to add that functionality to the product. In situations like this one it is difficult to estimate how long the research story will take.
考虑将尖峰放在不同的迭代中
如果可能，将调查故事放在一个迭代中，将其他故事放在一个或多个后续迭代中效果很好。通常，只能估计调查故事。将其他不可估计的故事与调查故事一起包含在同一迭代中意味着在该迭代中可以完成多少工作将存在高于正常水平的不确定性。
When possible, it works well to put the investigative story in one iteration and the other stories in one or more subsequent iterations. Normally, only the investigative story can be estimated. Including the other, non-estimatable stories in the same iteration with the investigative story means there will be a higher than normal level of uncertainty about how much can be accomplished in that iteration.
打破无法估计的故事的主要好处是，它允许客户将研究与新功能分开进行优先排序。如果客户只有要确定优先级的复杂故事（“为标准期望最大化添加新颖的扩展”）和对故事的估计，她可能会基于新功能将在大约该时间范围内交付的错误假设来确定故事的优先级。相反，如果客户有一个调查性故事（“研究并确定扩展期望最大化的可行性”）和一个功能性故事（“扩展期望最大化”），她必须在添加不添加新功能的调查性故事之间做出选择迭代，也许还有其他一些故事。
The key benefit of breaking out a story that cannot be estimated is that it allows the customer to prioritize the research separately from the new functionality. If the customer has only the complex story to prioritize (“Add novel extensions to standard expectation maximization”) and an estimate for the story, she may prioritize the story based on the mistaken assumption that the new functionality will be delivered in approximately that timeframe. If instead, the customer has an investigative, spike story (“research and determine the feasibility of extending expectation maximization”) and a functional story (“extend expectation maximization”), she must choose between adding the investigative story that adds no new functionality this iteration and perhaps some other story that does.
组合故事
Combining Stories
有时故事太小了。太小的故事通常是开发人员表示她不想写下或估计的故事，因为这样做可能比进行更改花费的时间更长。错误报告和用户界面更改是通常太小的故事的常见示例。对于极限编程团队中常见的小故事，一个好的方法是将它们组合成更大的故事，代表大约半天到几天的工作。组合的故事被赋予一个名称，然后像任何其他故事一样被安排和处理。
Sometimes stories are too small. A story that is too small is typically one that the developer says she doesn’t want to write down or estimate because doing that may take longer than making the change. Bug reports and user interface changes are common examples of stories that are often too small. A good approach for tiny stories, common among Extreme Programming teams, is to combine them into larger stories that represent from about a half-day to several days of work. The combined story is given a name and is then scheduled and worked on just like any other story.
例如，假设一个项目有五个错误，并且请求更改搜索屏幕上的某些颜色。开发人员估计涉及的总工作量整个系列被视为一个故事。如果您选择使用纸质记事卡，您可以将它们与封面卡片装订在一起。
For example, suppose a project has five bugs and a request to change some colors on the search screen. The developers estimate the total work involved and the entire collection is treated as a single story. If you’ve chosen to use paper note cards, you can do this by stapling them together with a cover card.
可测试
Testable
故事必须写成可测试的。成功通过它的测试证明一个故事已经成功开发。如果故事无法测试，开发人员如何知道他们何时完成编码？
Stories must be written so as to be testable. Successfully passing its tests proves that a story has been successfully developed. If the story cannot be tested, how can the developers know when they have finished coding?
不可测试的故事通常出现在非功能性需求中，这些需求是关于软件的需求，而不是直接关于其功能的需求。例如，考虑这些非功能性故事：
Untestable stories commonly show up for nonfunctional requirements, which are requirements about the software but not directly about its functionality. For example, consider these nonfunctional stories:
- 用户必须发现该软件易于使用。
- A user must find the software easy to use.
- 用户永远不必等待任何屏幕出现。
- A user must never have to wait long for any screen to appear.
如所写，这些故事不可测试。只要有可能，测试就应该自动化。这意味着争取 99% 的自动化，而不是 10%。您几乎总是可以实现比您想象的更多的自动化。当产品以增量方式开发时，事情会很快发生变化，昨天有效的代码今天可能会失效。您需要能够尽快找到它的自动化测试。
As written, these stories are not testable. Whenever possible, tests should be automated. This means strive for 99% automation, not 10%. You can almost always automate more than you think you can. When a product is developed incrementally, things can change very quickly and code that worked yesterday can stop working today. You want automated tests that will find this as soon as possible.
有一小部分测试实际上无法自动化。例如，可以测试“新手用户无需培训即可完成常见工作流”的用户故事，但不能自动化。测试这个故事可能需要让人为因素专家设计一个测试，该测试涉及观察随机抽样的代表性新手用户。这种类型的测试可能既耗时又昂贵，但故事是可测试的，可能适用于某些产品。
There is a very small subset of tests that cannot realistically be automated. For example, a user story that says “A novice user is able to complete common workflows without training” can be tested but cannot be automated. Testing this story will likely involve having a human factors expert design a test that involves observation of a random sample of representative novice users. That type of test can be both time-consuming and expensive, but the story is testable and may be appropriate for some products.
“用户永远不必等待任何屏幕出现”这个故事是不可测试的，因为它说的是“从不”，也因为它没有定义“等待很长时间”的含义。证明某事从未发生是不可能的。一个更容易、更合理的目标是证明某些事情很少发生。这个故事本可以写成“在 95% 的情况下，新屏幕会在两秒内出现。” 而且——更好的是——可以编写一个自动化测试来验证这一点。
The story “a user never has to wait long for any screen to appear” is not testable because it says “never” and because it does not define what “wait long” means. Demonstrating that something never happens is impossible. A far easier, and more reasonable target, is to demonstrate that something rarely happens. This story could have instead been written as “New screens appear within two seconds in 95% of all cases.” And—even better—an automated test can be written to verify this.
概括
Summary
- 理想情况下，故事彼此独立。这并不总是可能的，但在某种程度上，应该编写故事，以便它们可以按任何顺序开发。
- Ideally, stories are independent from one another. This isn’t always possible but to the extent it is, stories should be written so that they can be developed in any order.
- 故事的细节由用户和开发者协商。
- The details of a story are negotiated between the user and the developers.
- 故事应该写得清楚它们对用户或客户的价值。实现这一目标的最佳方式是让客户编写故事。
- Stories should be written so that their value to users or the customer is clear. The best way to achieve this is to have the customer write the stories.
- 故事可能会用细节进行注释，但过多的细节会掩盖故事的含义，并且会给人一种印象，即开发人员与客户之间无需进行对话。
- Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the developers and the customer.
- 注释故事的最佳方法之一是为故事编写测试用例。
- One of the best ways to annotate a story is to write test cases for the story.
- 如果它们太大，复合和复杂的故事可能会分成多个较小的故事。
- If they are too big, compound and complex stories may be split into multiple smaller stories.
- 如果它们太小，多个小故事可能会合并成一个更大的故事。
- If they are too small, multiple tiny stories may be combined into one bigger story.
- 故事需要是可测试的。
- Stories need to be testable.
开发者责任
Developer Responsibilities
- 您有责任帮助客户编写故事，这些故事承诺会进行交流而不是详细说明，对用户或客户有价值，是独立的，可测试的，并且大小合适。
- You are responsible for helping the customer write stories that are promises to converse rather than detailed specifications, have value to users or the customer, are independent, are testable, and are appropriately sized.
- 如果想要询问有关技术或基础设施的使用的故事，您有责任根据其对用户或客户的价值来描述需求。
- If tempted to ask for a story about the use of a technology or a piece of infrastructure, you are responsible for instead describing the need in terms of its value to users or the customer.
客户责任
Customer Responsibilities
- 您有责任编写故事，这些故事承诺会进行交流而不是详细说明，对用户或您自己有价值，是独立的，可测试的，并且大小合适。
- You are responsible for writing stories that are promises to converse rather than detailed specifications, have value to users or to yourself, are independent, are testable, and are appropriately sized.
问题
Questions
2.1 对于下列故事，请指出是不是好故事。如果不是，为什么？
2.1 For the following stories, indicate if it is a good story or not. If not, why?
一种。用户可以快速掌握该系统。
a. A user can quickly master the system.
b. 用户可以编辑简历上的地址。
b. A user can edit the address on a resume.
C。一个用户可以添加、编辑和删除多份简历。
c. A user can add, edit and delete multiple resumes.
d. 系统可以计算正态变量中二次型分布的鞍点近似值。
d. The system can calculate saddlepoint approximations for distributions of quadratic forms in normal variables.
e. 所有运行时错误都以一致的方式记录。
e. All runtime errors are logged in a consistent manner.
2.2 将这个史诗分成适当大小的组件故事：“用户可以制作和更改自动求职代理。”
2.2 Break this epic up into appropriately sized component stories: “A user can make and change automated job search agents.”
第 3 章用户角色建模
Chapter 3. User Role Modeling
在许多项目中，故事的编写就好像只有一种类型的用户一样。所有故事都是从该用户类型的角度编写的。这种简化是一种谬论，可能导致团队错过不符合系统主要用户类型一般模型的用户的故事。以使用为中心的设计 ( Constantine and Lockwood 1999 ) 和交互设计 ( Cooper 1999 ) 的原则告诉我们在编写故事之前识别用户角色和角色的好处。在本章中，我们将研究用户角色、角色建模、用户角色映射和角色，并展示采取这些初始步骤如何导致更好的故事和更好的软件。
On many projects, stories are written as though there is only one type of user. All stories are written from the perspective of that user type. This simplification is a fallacy and can lead a team to miss stories for users who do not fit the general mold of the system’s primary user type. The disciplines of usage-centered design (Constantine and Lockwood 1999) and interaction design (Cooper 1999) teach us the benefits of identifying user roles and personas prior to writing stories. In this chapter we will look at user roles, role modeling, user role maps, and personas and show how taking these initial steps leads to better stories and better software.
用户角色[1]
User Roles[1]
假设我们正在构建 BigMoneyJobs 职位发布和搜索网站。这种类型的站点将有许多不同类型的用户。当我们谈论用户故事时，我们谈论的用户是谁？我们是在谈论有工作但总是留意更好的工作的 Ashish 吗？我们是在谈论正在寻找第一份专业工作的新大学毕业生劳拉吗？我们是在谈论艾伦吗，他决定接受任何能让他每天下午搬到毛伊岛玩风帆冲浪的工作？或者我们在谈论斯科特，他并不讨厌自己的工作，但已经意识到是时候继续前进了？也许我们谈论的是 Kindra，他六个月前被解雇了，正在寻找一份好工作，但现在在美国东北部可以做任何事情。
Suppose we are building the BigMoneyJobs job posting and search site. This type of site will have many different types of users. When we talk about user stories, who is the user we’re talking about? Are we talking about Ashish who has a job but always keeps an eye out for a better one? Are we talking about Laura, a new college graduate looking for her first professional job? Are we talking about Allan, who has decided he’ll take any job that lets him move to Maui and windsurf every afternoon? Or are we talking about Scott, who doesn’t hate his job but has realized it’s time to move on? Perhaps we’re talking about Kindra who was laid off six months ago and was looking for a great job but will now take anything in the northeastern United States.
或者我们是否应该将用户视为来自发布职位的公司之一？也许用户是马里奥，从事人力资源和职位新职位空缺。也许用户是 Delaney，他也从事人力资源工作，但负责审查简历。或者用户可能是 Savannah，她是一名独立的招聘人员，正在寻找好工作和好人。
Or should we think of the user as coming from one of the companies posting the jobs? Perhaps the user is Mario, who works in human resources and posts new job openings. Perhaps the user is Delaney, who also works in human resources but is responsible for reviewing resumes. Or perhaps the user is Savannah, who works as an independent recruiter and is looking for both good jobs and good people.
显然，我们不能从单一的角度编写故事，也不能让这些故事反映每个用户的经历、背景和目标。Ashish 是一名会计师，他可能每月查看一次该网站，只是为了保持他的选择余地。Allan 是一名服务员，他可能想创建一个过滤器，以便在 Maui 上发布任何工作时随时通知他，但除非我们让它变得简单，否则他将无法做到这一点。Kindra 可能每天要花几个小时找工作，随着时间的推移她会扩大搜索范围。如果 Mario 和 Delaney 在一家有很多职位空缺的大公司工作，他们可能每天会在网站上花费四个或更多小时。
Clearly we cannot write stories from a single perspective and have those stories reflect the experiences, backgrounds and goals of each of these users. Ashish, an accountant, may look at the site once a month just to keep his options open. Allan, a waiter, may want to create a filter to notify him any time any job on Maui gets posted but he won’t be able to do that unless we make it easy. Kindra may spend hours each day looking for a job, broadening her search as time goes by. If Mario and Delaney work for a large company with many positions to fill, they may spend four or more hours a day on the site.
虽然每个用户都有不同的背景和不同的目标来使用您的软件，但仍然可以聚合单个用户并根据用户角色来考虑他们。用户角色是一组定义属性，这些属性描述了一群用户及其预期与系统的交互。因此，我们可以查看前面示例中的用户，并将他们分组为角色，如表 3.1所示，以这种方式划分角色。
While each user comes to your software with a different background and with different goals, it is still possible to aggregate individual users and think of them in terms of user roles. A user role is a collection of defining attributes that characterize a population of users and their intended interactions with the system. So, we could look at the users in the preceding example and group them into roles as shown in Table 3.1 into roles this way.
表 3.1。 BigMoneyJobs 项目的一个可能的角色列表。
Table 3.1. One possible list of roles for the BigMoneyJobs project.
自然地，不同的用户角色之间会有一些重叠。Job Seeker、First Timer、Layoff Victim、Geographic Searcher 和 Monitor 角色都将使用该站点的求职功能。他们可能会以不同的方式和不同的频率使用它们，但他们使用该系统的方式在很大程度上是相似的。Resume Reader 和 Job Poster 的角色也可能会重叠，因为这些角色都追求寻找优秀候选人的相同目标。
Naturally, there will be some overlap between different user roles. The Job Seeker, First Timer, Layoff Victim, Geographic Searcher, and Monitor roles will all use the job search features of the site. They may use them in different ways and at different frequencies, but much of how they use the system will be similar. The Resume Reader and Job Poster roles will probably overlap as well since these roles are both pursuing the same goal of finding good candidates.
表 3.1并未显示将 BigMoneyJobs 的用户分组为角色的唯一可能方法。例如，我们可以选择包括像 Part-Timer 这样的角色，全职和承包商。在本章的其余部分，我们将研究如何列出角色列表以及如何完善该列表以使其发挥作用。
Table 3.1 does not show the only possible way to group users of BigMoneyJobs into roles. For example, we could choose to include roles like Part-Timer, Full-Timer and Contractor. In the rest of this chapter we’ll look at how to come up with a list of roles and how to refine that list so that it is useful.
角色建模步骤
Role Modeling Steps
我们将使用以下步骤来识别和选择一组有用的用户角色：
We will use the following steps to identify and select a useful set of user roles:
- 集体讨论一组初始用户角色
- brainstorm an initial set of user roles
- 组织初始集
- organize the initial set
- 巩固角色
- consolidate roles
- 细化角色
- refine the roles
以下各节将讨论其中的每个步骤。
Each of these steps is discussed in the following sections.
集思广益初始用户角色集
Brainstorming an Initial Set of User Roles
为了确定用户角色，客户和尽可能多的开发人员在一个房间里会面，房间里有一张大桌子或一面墙，他们可以用胶带或别针卡贴在上面。将启动项目的用户角色建模的整个团队包括在内总是理想的，但这不是必需的。只要开发人员的合理代表与客户一起出现，您就可以获得成功的会话。
To identify user roles, the customer and as many of the developers as possible meet in a room with either a large table or a wall to which they can tape or pin cards. It’s always ideal to include the full team for the user role modeling that initiates a project but it’s not necessary. As long as a reasonable representation of the developers is present along with the customer, you can have a successful session.
每个参与者从放在桌子中间的一堆中抓起一叠记事卡。（即使您计划以电子方式存储用户角色，您也应该首先将它们写在卡片上。）首先让每个人在卡片上写下角色名称，然后将它们放在桌子上，或者用胶带粘住或钉在墙上。
Each participant grabs a stack of note cards from a pile placed in the middle of the table. (Even if you plan to store the user roles electronically you should start by writing them on cards.) Start with everyone writing role names on cards and then placing them on a table, or taping or pinning them to a wall.
当放置新的角色卡时，作者会说出新角色的名称，仅此而已。由于这是一次头脑风暴会议，因此没有讨论卡片或评估角色。相反，每个人都写了他或她能想到的尽可能多的卡片。没有轮流，你不会绕着桌子四处寻找新角色。每个参与者只要想到一个新角色就写一张卡片。
When a new role card is placed, the author says the name of the new role and nothing more. Since this is a brainstorming session, there is no dicsussion of the cards or evaluation of the roles. Rather, each person writes as many cards as he or she can think of. There are no turns, you don’t go around the table asking for new roles. Each participant just writes a card whenever she thinks of a new role.
在对角色进行头脑风暴时，房间里会充满笔在卡片上刮擦的声音，偶尔会有人放一张新卡片并读出角色的名字。继续，直到进展停滞，参与者很难想出新的角色。那时你可能还没有确定所有的角色，但你已经足够接近了。这很少需要持续超过十五分钟。
While brainstorming roles, the room will be filled with sounds of pens scratching on cards and will be punctuated by someone occasionally placing a new card and reading the name of the role. Continue until progress stalls and participants are having a hard time thinking up new roles. At that point you may not have identified all of the roles but you’re close enough. Rarely does this need to last longer than fifteen minutes.
用户角色是一个用户
在对项目的角色进行头脑风暴时，坚持识别代表单个用户的角色。例如，对于 BigMoneyJobs 项目，编写诸如“公司可以发布职位空缺”之类的故事可能很诱人。但是，由于公司作为一个整体不能使用该软件，所以如果提到一个代表个人的角色，故事会更好。
When brainstorming a project’s roles, stick to identifying roles that represent a single user. For example, for the BigMoneyJobs project it may be tempting to write stories such as “A company can post a job opening.” However, since a company as a whole cannot use the software, the story will be better if it refers to a role that represents an individual.
组织初始集
Organizing the Initial Set
一旦小组完成角色识别，就该组织他们了。为此，将卡片在桌子或墙上四处移动，以便它们的位置指示角色之间的关系。放置重叠角色，以便他们的卡片重叠。如果角色有一点重叠，请将卡片重叠一点。如果角色完全重叠，则将卡片完全重叠。示例如图 3.1所示。
Once the group has finished identify roles, it’s time to organize them. To do this, cards are moved around on the table or wall so that their positions indicate the relationships between the roles. Overlapping roles are placed so that their cards overlap. If the roles overlap a little, overlap the cards a little. If the roles overlap entirely, overlap the cards entirely. An example is shown in Figure 3.1.
图 3.1。 在桌子上组织用户角色卡。
Figure 3.1. Organizing the user role cards on a table.
图 3.1显示大学毕业生和新手，正如他们的卡片作者所期望的那样，这些角色明显重叠。代表将使用该网站搜索工作的人的其他卡片之间的重叠较少但相似。Monitor 角色卡显示时只有轻微的重叠，因为该角色指的是在当前工作中相对快乐但喜欢睁大眼睛的人。
Figure 3.1 shows that the College Grad and First Timer, as those roles were intended by their card writers, overlap signficantly. There’s less but similar overlap among the other cards representing people who will use the site to search for jobs. The Monitor role card is shown with only a slight overlap because that role refers to someone who is relatively happy in her current job but likes to keep her eyes open.
图 3.1中求职角色的右侧是职位发布者、招聘人员和简历阅读者角色卡。招聘人员角色显示为与职位发布者和简历阅读者重叠，因为招聘人员将同时发布广告并阅读简历。还显示了管理员角色。此角色代表将支持系统的 BigMoneyJobs 内部用户。
To the right of the job-seeking roles in Figure 3.1 are the Job Poster, Recruiter, and Resume Reader role cards. The Recruiter role is shown overlapping both Job Poster and Resume Reader because a recruiter will both post ads and read resumes. An Administrator role is shown also. This role represents users internal to BigMoneyJobs who will support the system.
系统角色
尽可能多地坚持定义人的用户角色，而不是其他系统。如果您认为这会有所帮助，则偶尔确定一个非人类用户角色。然而，确定用户角色的目的是确保我们认真考虑我们绝对、积极地必须对新系统感到满意的用户。我们不需要为系统的每个可以想象的用户分配用户角色，但我们需要为那些能够成就或破坏项目成功的人分配角色。由于其他系统很少是我们系统的购买者，因此他们很少能成就或破坏我们系统的成功。当然，也有例外，如果您觉得添加非人类用户角色有助于您考虑您的系统，那么添加它。
As much as you can, stick with user roles that define people, as opposed to other systems. If you think it will help, then identify an occasional non-human user role. However, the purpose of identifying user roles is to make sure that we think really hard about the users that we absolutely, positively must satisfy with the new system. We don’t need user roles for every conceivable user of the system, but we need roles for the ones who can make or break the success of the project. Since other systems are rarely purchasers of our system, they can rarely make or break the success of our system. Naturally, there can be exceptions to this and if you feel that adding a non-human user role helps you think about your system, then add it.
巩固角色
Consolidating Roles
角色分组后，尝试巩固和压缩角色。从完全重叠的卡片开始。重叠卡片的作者描述了这些角色名称的含义。经过简短的讨论后，小组决定角色是否等同。如果相等，则可以将这些角色合并为一个角色（可能以两个初始角色的名字命名），或者撕掉其中一张初始角色卡。
After the roles have been grouped, try to consolidate and condense the roles. Start with cards that are entirely overlapping. The authors of overlapping cards describe what they meant by those role names. After a brief discusson the group decides if the roles are equivalent. If equivalent, the roles can either be consolidated into a single role (perhaps taking its name from the two initial roles), or one of the initial role cards can be ripped up.
在图 3.1中，College Grad 和 First Timer 角色显示为高度重叠。该小组决定撕掉 College Grad 卡片，因为该用户角色的任何故事都可能与 First Timer 的故事相同。尽管 First Timer、Layoff Victim、Geographic Searcher 和 Job Seeker 有很大的重叠，但该小组决定每个人都代表一个重要的选区，并且这些角色对于如何使用 BigMoneyJobs 网站具有重要但略有不同的目标。
In Figure 3.1 the College Grad and First Timer roles are shown as heavily overlapping. The group decides to rip up the College Grad card since any stories for that user role would likely be identical to stories for a First Timer. Even though First Timer, Layoff Victim, Geographic Searcher and Job Seeker have significant overlap, the group decides that each represents a constituency that will be important to satisfy and the roles will have important but subtly different goals for how they use the BigMoneyJobs website.
当他们查看图 3.1的右侧时，小组认为不值得区分职位发布者和简历阅读者。他们决定招聘人员充分涵盖这两个角色，然后撕掉这些卡片。但是，该小组认为内部招聘人员（为特定公司工作）和外部招聘人员（为任何公司的工作匹配候选人）之间存在差异。他们为内部招聘人员和外部招聘人员创建新卡片，并将它们视为招聘人员角色的特殊版本。
When they look at the right side of Figure 3.1, the group decides that it is not worth distinguishing between a Job Poster and a Resume Reader. They decide that a Recruiter covers these two roles adequately and those cards are ripped up. However, the group decides that there are differences between an Internal Recruiter (working for a specific company) and an External Recruiter (matching candidates to jobs at any company). They create new cards for Internal Recruiter and External Recruiter, and consider these as specialized versions of the Recruiter role.
除了巩固重叠的角色外，该小组还应该撕掉所有对系统成功不重要的角色的角色卡。例如，Monitor 角色卡代表只关注就业市场的人。监督员不得在三年内更换工作。BigMoneyJobs 可能在不关注该用户角色的情况下做得很好。他们决定最好专注于对公司成功至关重要的角色，例如求职者和招聘人员角色。
In addition to consolidating overlapping roles, the group should also rip up any role cards for roles that are unimportant to the success of the system. For example, the Monitor role card represents someone who is just keeping an eye on the job market. A Monitor may not switch jobs for three years. BigMoneyJobs can probably do quite well without paying attention to that user role. They decide they will be better off focusing on the roles that will be important to the success of the company, such as Job Seeker and the Recruiter roles.
团队整理卡片后，将它们排列在桌子或墙上，以显示角色之间的关系。图 3.2显示了 BigMoneyJobs 角色卡的许多可能布局之一。在这里，通用角色（例如求职者或招聘人员）位于该角色的特殊版本之上。或者，可以按照小组希望的任何其他方式堆叠或放置卡片，以显示他们认为重要的任何关系。
After the team has consolidated the cards, they are arranged on the table or wall to show relationships between the roles. Figure 3.2 shows one of many possible layouts for the BigMoneyJobs role cards. Here a generic role, such as Job Seeker or Recruiter, is positioned above specialized versions of that role. Alternatively, cards can be stacked or positioned in any other way that the group desires in order to show whatever relationships they think are important.
图 3.2。 综合角色卡。
Figure 3.2. The consolidated role cards.
细化角色
Refining the Roles
一旦我们整合了角色并对角色之间的关系有了基本的了解，就可以通过定义每个角色的属性来对这些角色进行建模。角色属性是关于履行角色的用户的一个事实或一些有用的信息。将一个角色与另一个角色区分开来的关于用户角色的任何信息都可以用作角色属性。在准备任何角色模型时，以下是一些值得考虑的属性：
Once we’ve consolidated roles and have a basic understanding for how the roles relate to each other, it is possible to model those roles by defining attributes of each role. A role attribute is a fact or bit of useful information about the users who fulfill the role. Any information about the user roles that distinguishes one role from another may be used as a role attribute. Here are some attributes worth considering when preparing any role model:
- 用户使用软件的频率。
- The frequency with which the user will use the software.
- 用户在域中的专业水平。
- The user’s level of expertise with the domain.
- 用户对计算机和软件的一般熟练程度。
- The user’s general level of proficiency with computers and software.
- 用户对正在开发的软件的熟练程度。
- The user’s level of proficiency with the software being developed.
- 用户使用软件的总体目标。有些用户追求便利，有些则喜欢丰富的体验，等等。
- The user’s general goal for using the software. Some users are after convenience, others favor a rich experience, and so on.
除了这些标准属性之外，您还应该考虑正在构建的软件，看看是否有任何可能对描述其用户有用的属性。例如，对于 BigMoneyJobs 网站，您可能需要考虑用户角色是寻找兼职还是全职工作。
Beyond these standard attributes you should consider the software being built and see if there are any attributes that might be useful in describing its users. For instance, for the BigMoneyJobs website you may want to consider whether the user role will be looking for a part-time or full-time job.
当您确定角色的有趣属性时，请在角色卡上写下注释。完成后，您可以将角色卡挂在团队使用的公共区域，以便它们用作提醒。示例用户角色卡如图 3.3所示。
As you identify interesting attributes for a role, write notes on the role card. When finished, you can hang the role cards in a common area used by the team so they can be used as reminders. A sample user role card is shown in Figure 3.3.
图 3.3。 示例用户角色卡。
Figure 3.3. A sample user role card.
两种附加技术
Two Additional Techniques
如果我们愿意，我们现在可以停下来。到目前为止，一个团队可能已经花费了一个小时——几乎肯定不会超过这个小时——而且他们对软件用户的考虑可能比所有软件团队的 99% 都多。事实上，大多数团队应该在这一点上停下来。然而，还有两种额外的技术值得指出，因为它们可能有助于考虑某些项目的用户。仅当您可以预期对项目有直接、切实的好处时才使用这些技术。
We could stop right now if we want to. By now a team might have spent an hour—almost certainly no more than that—and they will have put more thought into the users of their software than probably 99% of all software teams. Most teams should, in fact, stop at this point. However, there are two additional techniques that are worth pointing out because they may be helpful in thinking about users on some projects. Only use these techniques if you can anticipate a direct, tangible benefit to the project.
角色
Personas
识别用户角色是一个巨大的飞跃，但对于一些更重要的用户角色，可能值得更进一步并为角色创建角色。角色是用户角色的想象表示。在本章的前面，我们遇到了马里奥，他负责为他的公司发布新的职位空缺。创建角色需要的不仅仅是为用户角色添加名称。应该充分描述一个角色，让团队中的每个人都觉得他们了解这个角色。例如，马里奥可能被描述如下：
Identifying user roles is a great leap forward, but for some of the more important user roles, it might be worth going one step further and creating a persona for the role. A persona is an imaginary representation of a user role. Earlier in this chapter we met Mario who is responsible for posting new job openings for his company. Creating a persona requires more than just adding a name to a user role. A persona should be described sufficiently that everyone on the team feels like they know the persona. For example, Mario may be described as follows:
Mario 在高端网络组件制造商 SpeedyNetworks 的人事部门担任招聘人员。他在 SpeedyNetworks 工作了六年。马里奥有弹性工作时间安排，每周五在家工作。Mario 非常精通计算机，并且认为自己是他使用的几乎所有产品的超级用户。Mario 的妻子 Kim 即将完成她的博士学位。斯坦福大学化学专业。由于 SpeedyNetworks 几乎一直在持续增长，因此马里奥一直在寻找优秀的工程师。
Mario works as a recruiter in the Personnel department of SpeedyNetworks, a manufacturer of high-end networking components. He’s worked for SpeedyNetworks six years. Mario has a flex-time arrangement and works from home every Friday. Mario is very strong with computers and considers himself a power user of just about all the products he uses. Mario’s wife, Kim, is finishing her Ph.D. in chemistry at Stanford University. Because SpeedyNetworks has been growing almost consistently, Mario is always looking for good engineers.
如果您选择为您的项目创建人物角色，请注意已经完成足够的市场和人口统计研究，以使所选人物角色真正代表产品的目标受众。
If you choose to create personas for your project, be careful that enough market and demographic research has been done that the personas chosen truly represent the product’s target audience.
这个角色描述很好地介绍了马里奥。然而，没有什么比图片更能说明问题了，因此您还应该找一张马里奥的图片并将其包含在角色定义中。您可以从网上到处获取照片，也可以从杂志上剪下一张。完整的角色定义与照片相结合，可以让团队中的每个人都对角色有一个全面的了解。
This persona description gives us a good introduction to Mario. However, nothing speaks as loudly as a picture, so you should also find a picture of Mario and include that with the persona definition. You can get photographs all over the web or you can cut one from a magazine. A solid persona definition combined with a photograph will give everyone on the team a thorough introduction to the persona.
大多数角色定义太长，无法放在便条卡上，所以我建议您将它们写在一张纸上，然后挂在团队的公共空间。您不需要为每个用户角色编写角色定义。但是，您可以考虑为一个或两个主要用户角色编写角色定义。如果您正在构建的系统使得产品满足一个或两个用户角色是绝对重要的，那么这些用户角色就是扩展到角色的候选者。
Most persona definitions are too long to fit on a note card, so I suggest you write them on a piece of paper and hang them in the team’s common space. You do not need to write persona definitions for every user role. You may, however, think about writing a persona definition for one or two of the primary user roles. If the system you are building is such that it is absolutely vital that the product satisfy one or two user roles, then those user roles are candidates for expansion into personas.
当根据用户角色或角色放置时，故事变得更具表现力。在您确定了用户角色和可能的一两个角色之后，您可以开始用角色和角色而不是更通用的“用户”来说话。与其写像“用户可以将职位搜索限制在特定地理区域”这样的故事，不如写成“地理搜索者可以限制他的工作搜索到特定的地理区域。” 希望以这种方式写故事能让团队想起艾伦，他正在毛伊岛找工作。用用户角色或角色名称编写一些故事并不意味着其他角色不能执行这些故事；相反，这意味着在讨论或编写故事时考虑特定的用户角色或角色会有一些好处。
Stories become much more expressive when put in terms of a user role or persona. After you have identified user roles and possibly a persona or two, you can begin to speak in terms of roles and personas instead of the more generic “the user.” Rather than writing stories like “A user can restrict job searches to specific geographic regions” you can write “A Geographic Searcher can restrict his job searches to a specific geographic region.” Hopefully writing a story this way reminds the team about Allan who is looking for any job on Maui. Writing some stories with user role or persona names does not mean that other roles cannot perform those stories; rather, it means that there is some benefit in thinking about a specific user role or persona when discussing or coding the story.
极端人物
Extreme Characters
Djajadiningrat 和合著者 (2000)提出了您可能需要考虑的第二种技术：在考虑设计新系统时使用极端字符。他们描述了一个设计个人数字助理 (PDA) 掌上电脑的例子。他们建议，系统设计者不应只为典型的衣冠楚楚、驾驶宝马的管理顾问进行设计，而应考虑个性夸张的用户。具体而言，作者建议为一名毒贩、教皇和一名正在兼顾多个男朋友的 20 岁女性设计 PDA。
Djajadiningrat and co-authors (2000) have proposed a second technique you might want to think about: the use of extreme characters when considering the design of a new system. They describe an example of designing a Personal Digital Assistant (PDA) handheld computer. They advise that instead of designing solely for a typical sharp-dressed, BMW-driving management consultant, the system designers should consider users with exaggerated personalities. Speficially, the authors suggest designing the PDA for a drug dealer, the Pope, and a twenty-year-old woman who is juggling multiple boyfriends.
考虑极端人物很可能会引导您找到您可能会错过的故事。例如，很容易想象毒贩和一个有几个男朋友的女人可能每个人都想维护多个单独的时间表，以防警察或男朋友看到 PDA。教皇可能不太需要保密，但可能需要更大的字体。
It is very possible that considering extreme characters will lead you to stories you would be likely to miss otherwise. For example, it is easy to imagine that the drug dealer and a woman with several boyfriends may each want to maintain multiple separate schedules in case the PDA is seen by the police or a boyfriend. The Pope probably has less need for secrecy but may want a larger font size.
因此，虽然极端人物可能会带来新的故事，但很难知道这些故事是否应该包含在产品中。这可能不值得投入太多时间，但您可能想尝试极端角色。至少，您可以花几分钟的时间思考教皇如何使用您的软件，这可能会带来一两个见解。
So, while extreme characters may lead to new stories, it is hard to know whether those stories will be ones that should be included in the product. It is probably not worth much investment in time, but you might want to experiment with extreme characters. At a minimum, you can have a few minutes of fun thinking about how the Pope might use your software and it just may lead to an insight or two.
如果我有现场用户怎么办？
What If I Have On-Site Users?
即使您的建筑物中有真实的用户，本章中描述的用户角色建模技术仍然有用。与真实用户合作将极大地提高您交付所需软件的可能性。然而，即使是真实用户，也不能保证您拥有正确的用户或正确的用户组合。
The user role modeling techniques described in this chapter are still useful even if you have real, live users in your building. Working with real users will strongly improve your likelihood of delivering the desired software. However, even with real users there is no guarantee that you have the right users or the right mix of users.
为了减少无法满足重要用户的可能性，即使您有可用的内部用户，您也应该对项目进行一些简单的角色建模。
To decrease the likelihood of failing to satisfy important users, you should do some simple role modeling on projects even when you have available internal users.
概括
Summary
- 大多数项目团队只考虑单一类型的用户。这导致软件忽略了至少某些用户类型的需求。
- Most project teams consider only a single type of user. This leads to software that ignores the needs of at least some user types.
- 为避免从单个用户的角度编写所有故事，请确定将与软件交互的不同用户角色。
- To avoid writing all stories from the perspective of a single user, identify the different user roles who will interact with the software.
- 通过为每个用户角色定义相关属性，您可以更好地看到角色之间的差异。
- By defining relevant attributes for each user role, you can better see the differences between roles.
- 一些用户角色受益于人物角色的描述。角色是用户角色的想象表示。角色被赋予一个名字、一张脸和足够的相关细节，使他们看起来对项目成员来说是真实的。
- Some user roles benefit from being described by personas. A persona is an imaginary representation of a user role. The persona is given a name, a face, and enough relevant details to make them seem real to the project members.
- 对于某些应用程序，极端字符可能有助于寻找否则会被遗漏的故事。
- For some applications, extreme characters may be helpful in looking for stories that would otherwise be missed.
开发者责任
Developer Responsibilities
- 您有责任参与识别用户角色和角色的过程。
- You are responsible for participating in the process of identifying user roles and personas.
- 您有责任了解每个用户角色或角色及其不同之处。
- You are responsible for understanding each of the user roles or personas and how they differ.
- 在开发软件时，您有责任考虑不同的用户角色可能更喜欢软件的行为方式。
- While developing the software, you are responsible for thinking about how different user roles may prefer the software to behave.
- 您有责任确保识别和描述用户角色不会超出其作为流程中的工具的角色。
- You are responsible for making sure that identifying and describing user roles does not go beyond its role as a tool in the process.
客户责任
Customer Responsibilities
- 您负责广泛查看可能的用户空间并确定适当的用户角色。
- You are responsible for looking broadly across the space of possible users and identifying appropriate user roles.
- 您有责任参与识别用户角色和角色的过程。
- You are responsible for participating in the process of identifying user roles and personas.
- 您有责任确保该软件不会不适当地关注一部分用户。
- You are responsible for ensuring that the software does not focus inappropriately on a subset of users.
- 在编写故事时，您将负责确保每个故事都可以与至少一个用户角色或角色相关联。
- When writing stories you will be responsible for ensuring that each story can be associated with at least one user role or persona.
- 在开发软件时，您有责任考虑不同的用户角色可能更喜欢软件的行为方式。
- While developing the software, you are responsible for thinking about how different user roles may prefer the software to behave.
- 您有责任确保识别和描述用户角色不会超出其作为流程中的工具的角色。
- You are responsible for making sure that identifying and describing user roles does not go beyond its role as a tool in the process.
问题
Questions
3.1 看看 eBay 网站。您可以识别哪些用户角色？
3.1 Take a look at the eBay website. What user roles can you identify?
3.2 整合你在上一个问题中想到的角色，并展示你将如何布置角色卡。解释你的答案。
3.2 Consolidate the roles you came up with in the previous question and show how you would lay out the role cards. Explain your answer.
3.3 为最重要的用户角色编写角色描述。
3.3 Write persona descriptions for the one most important user role.
第 4 章收集故事
Chapter 4. Gathering Stories
你如何收集故事？本章提供了与用户合作的建议，以便在与他们的对话中识别故事。将描述各种方法的优点。本章描述了通过提出正确类型的问题来了解用户真正需求的有效方法。
How do you gather the stories? This chapter offers advice on working with users in order to identify stories in your conversations with them. The advantages of various approaches will be described. This chapter describes effective methods for getting at a user’s real needs by asking the right types of questions.
诱导和捕获应该是非法的
Elicitation and Capture Should Be Illicit
甚至一些关于需求的最佳书籍也使用诸如启发（ Kovitz 1999 年；Lauesen 2002 年；Wiegers 1999 年）和捕获（Jacobson、Booch 和 Rumbaugh 1999 年）之类的词来描述识别需求的实践。像这样的术语暗示要求在某处存在，我们需要做的就是向我们解释它们，然后我们可以将它们锁在笼子里。项目空间中并没有等待捕获的需求。同样，用户并不是已经知道所有需求，我们只需要引出它们即可。
Even some of the best books on requirements use words like elicitation (Kovitz 1999; Lauesen 2002; Wiegers 1999) and capture (Jacobson, Booch and Rumbaugh 1999) to describe the practice of identifying requirements. Terms like these imply requirements are out there somewhere and all we need to do is have them explained to us and then we can lock them in a cage. Requirements are not out there in the project space waiting to be captured. Similarly, it is not the case that users already know all the requirements and we need only elicit them.
Robertson 和 Robertson (1999)引入了术语拖网来描述收集需求的过程。需求拖网导致心理图像，即需求被捕获在被拖在船后的渔网中。这个比喻适用于多个层面。
Robertson and Robertson (1999) introduce the term trawling to describe the process of gathering requirements. Trawling for requirements leads to the mental image that requirements are captured in a fishing net being pulled behind a boat. This metaphor works on a variety of levels.
首先，它与不同大小的网络可以捕获不同大小的需求的想法是一致的。可以用大网状网在需求池塘上进行第一遍以获得所有大的。您可以从大需求中了解所需的软件，然后通过较小的网格网络进行后续传递并获得中型需求，仍然将小需求留到以后使用。无论我们是否将规模视为商业价值、软件的必要性等，这个比喻都适用。
First, it is consistent with the idea that different-sized nets can be used to capture different-sized requirements. A first pass can be made over the requirements pond with a large mesh net to get all the big ones. You can get a feel for the needed software from the big requirements and then make a subsequent pass with a smaller mesh net and get the medium-sized requirements, still leaving the small ones for later. This metaphor works whether we think of size as business value, essentialness to the software, and so on.
其次，对需求的拖网表达了需求像鱼一样成熟并可能死亡的想法。今天我的网络可能会漏掉一个需求，因为这个需求对系统来说并不重要。然而，随着系统的发展根据每次迭代的反馈，不可预测的方向，一些需求会变得越来越重要。同样，曾经被认为重要的其他需求的重要性将下降到我们可以认为它们已死的程度。
Second, trawling for requirements expresses the idea that requirements, like fish, mature and possibly die. My net may miss a requirement today because the requirement is not important to the system. However, as the system grows in unpredictable directions based on the feedback from each iteration, some requirements will grow in importance. Similarly, other requirements that were once considered important will decrease in importance to the point where we can consider them dead.
第三，就像你不会通过拖网捕捞一个区域的所有鱼一样，你也不会捕获所有的需求。然而，就像拖网捕鱼一样，当您拖网寻找需求时，您很可能捕获到使需求膨胀的漂浮物和垃圾。
Third, just like you won’t catch all of the fish in an area by trawling, you won’t capture all of the requirements. However, just as with trawling for fish, when you trawl for requirements you are likely to capture the flotsam and jetsam that bloat requirements.
最后，需求拖网的比喻抓住了一个重要的事实，即技能在寻找需求中起着重要作用。熟练的需求拖网者将知道在哪里寻找需求，而不熟练的拖网者将浪费时间在低效的技术上或在错误的位置。本章是关于学习使我们有效地拖网用户故事的技术。
Finally, the metaphor of trawling for requirements captures the important reality that skill plays a factor in finding the requirements. A skilled requirements trawler will know where to look for requirements, while the unskilled trawler will waste time with inefficient techniques or in the wrong locations. This chapter is about learning the techniques that make us efficient in trawling for user stories.
一点点就够了吗？
A Little Is Enough, or Is It?
发现传统规范过程的最简单方法之一是查看其满足需求的方法。说明性过程的特点是非常强调在项目早期就正确获取所有需求并编写。另一方面，敏捷项目承认不可能使用具有如此精细网格的网络，以至于我们可以一次性获得所有用户故事。敏捷流程还承认故事有一个时间维度：故事的相关性会随着时间的流逝以及在先前迭代中添加到产品中的故事而变化。
One of the easiest ways to spot a traditional prescriptive process is to look at its approach to requirements. Prescriptive processes are characterized by their heavy emphasis on getting all the requirements right and written early in the project. Agile projects, on the other hand, acknowledge that it is impossible to use a net with such a fine mesh that we can get all of the user stories in one pass. Agile processes also acknowledge that there is a time dimension to stories: the relevance of a story changes based on the passage of time and on what stories were added to the product in prior iterations.
然而，即使我们承认不可能为一个项目编写所有的故事，我们仍然应该尽早尝试编写我们可以编写的故事，即使许多是在非常高的水平上编写的。使用故事的优点之一是很容易在不同的细节层次上编写它们。我们可以写“A user can search for jobs”作为占位符，或者因为当时我们只知道这些。然后，我们可以将该故事演变成更小、更有用的故事。正因为如此，与其他需求技术相比，为应用程序的大部分编写故事非常容易，而且工作量更少。
However, even though we acknowledge the impossibility of writing all of the stories for a project, we should still make an initial upfront attempt to write those that we can, even if many are written at a very high level. One of the advantages of working with stories is that it is very easy to write them at different levels of detail. We can write “A user can search for jobs” either as a placeholder or because that’s all we know at the time. We can then evolve that story into smaller, more useful stories later. Because of this, it is very easy to write stories for a large portion of an application with less work than with other requirements techniques.
这不是通过花费三个月编写用户故事来开始新项目的建议。相反，它意味着展望未来大约一个版本（可能三到六个月），然后编写随着时间范围的增加而减少细节的用户故事。例如，如果客户或者用户说他们“可能需要此版本中的报告”，然后写一张卡片，简单地说“用户可以运行报告”。但就此打住：不要确定他们是否需要配置自己的报告，报告是否采用 HTML 格式，或者报告是否可以保存。
This is not a recommendation to start a new project by spending three months writing user stories. Rather, it means to look into the future for approximately one release (perhaps three to six months) and then write user stories that decrease in detail as the time horizon increases. For example, if the customer or users have said they “probably want reports in this release” then write a card that simply says “A user can run reports.” But stop there: don’t determine if they need to configure their own reports, whether reports are formatted in HTML, or whether reports can be saved.
同样，在启动应用程序之前很久就对应用程序的大小有一个整体的了解通常很重要。在获得启动项目的资金和批准之前，通常需要大致了解项目的成本和收益。要知道这些问题的答案，至少需要对构成该项目的故事进行一些预先考虑。
Similarly, it is often important to get an overall feel for the size of an application long in advance of starting it. It is often necessary to have a rough idea of what a project will cost and what benefits it will deliver before getting funding and approval to start the project. To know the answers to these questions requires at least a little forethought into the stories that will comprise the project.
技巧
Techniques
因为故事会在整个项目中不断演变、出现和消失，所以我们需要一套可以迭代使用的技术来收集它们。我们使用的技术必须足够轻巧且不引人注目，以便或多或少可以连续应用。创建一组故事的一些最有价值的技术是：
Because stories will be evolving, coming and going throughout the project, we need a set of techniques for gathering them that can be used iteratively. The techniques we use must be sufficiently lightweight and non-obtrusive that they can be applied more or less continuously. Some of the most valuable techniques for creating a set of stories are:
- 用户访谈
- User interviews
- 调查问卷
- Questionnaires
- 观察
- Observation
- 故事写作工作坊
- Story-Writing workshops
许多这些技术都在传统业务分析师的工具包中。有业务分析师可用的项目应该利用她来做大量的故事拖网。
Many of these techniques are in the toolkit of the traditional business analyst. Projects with a business analyst available should make use of her to do much of the trawling for stories.
以下各节将考虑这些技术中的每一种。
Each of these techniques will be considered in the following sections.
用户访谈
User Interviews
采访用户是许多团队用来拖网搜索故事的默认方法，并且可能是您想要使用的方法。采访成功的关键之一是采访对象的选择。正如第 5 章“使用用户代理”中所讨论的，有许多可用的用户代理；但是您显然应该尽可能采访真实用户。您还应该采访担任不同用户角色的用户。
Interviewing users is the default approach many teams take to trawling for stories and is probably one you will want to use. One of the keys to success with interviews is the selection of interviewees. As discussed in Chapter 5, “Working with User Proxies,” there are many user proxies available; but you should obviously interview real users whenever possible. You should also interview users who fill different user roles.
仅仅询问用户“那么，你需要什么？”是不够的。大多数用户不太善于理解，尤其是不善于表达他们的真实需求。我曾经从一位走进我办公室的用户那里了解到这一点，他承认，“你完全按照我的要求构建了它，但这不是我想要的。”
It is not sufficient to ask the user “So, what do you need?” Most users are not very adept at understanding, and especially at expressing, their true needs. I learned this once from a user who walked into my office and acknowledged, “You built exactly what I asked for but it’s not what I want.”
我与一个正在开发用于提供调查的软件的团队合作。每项调查都将通过电话、电子邮件和交互式语音响应进行。不同类型的用户会使用不同的调查类型。调查非常复杂：一组问题的具体答案将决定接下来要问哪个问题。用户需要一种进入调查的方式，他们向开发团队展示了他们提出的用于制定问题的复杂微型语言的示例。对于其中一位开发人员来说，这种完全基于文本的方法似乎不必要地复杂。开发人员向用户展示了他们如何通过拖放代表调查中不同类型问题的图标来可视化地创建调查。用户撕掉了他们的迷你语言，并与开发人员合作创建了一个可视化调查设计工具。仅仅因为这些用户遇到了问题并不意味着他们是唯一有资格提出解决方案的人。
I worked with a team that was developing software for delivering surveys. Each survey would be delivered over the phone, via email, and via interactive voice response. Different types of users would use different survey types. The surveys were very complicated: specific answers to one set of questions would determine which question would be asked next. The users needed a way to enter the surveys and they presented the development team with examples of a complicated mini-language they proposed using to formulate questions. This entirely text-based approach seemed needlessly complicated to one of the developers. The developer showed the users how they could instead create surveys visually by dragging and dropping icons that represented different types of questions in a survey. The users ripped up their mini-language and worked with the developers to create a visual survey design tool. Just because these users had the problem does not mean they were uniquely qualified to propose its solution.
开放式和上下文无关的问题
Open-Ended and Context-Free Questions
了解用户需求本质的最佳方法是通过您提出的问题。我与一个项目团队一起工作，他们在将应用程序放在浏览器中或将其编写为更传统的特定于平台的程序之间左右为难。他们在基于浏览器的版本和更强大的特定于平台的客户端提供的易于部署和较低的培训成本之间挣扎。目标用户当然喜欢浏览器的优势，但他们也看重特定平台客户端提供的更丰富的用户体验。
The best technique for getting to the essence of a user’s needs is through the questions you ask. I worked with a project team that was torn between putting their application in a browser or writing it as a more traditional platform-specific program. They struggled between the ease-of-deployment and lower training costs provided by the browser-based version and the more powerful platform-specific client. The intended users would certainly like the advantages of the browser, but they also valued the richer user experience provided by the platform-specific client.
建议询问产品的目标用户的偏好。由于该产品将是旧产品的新一代重写，营销团队同意联系当前用户的代表性样本。调查中的每个用户都被问及“你喜欢我们在浏览器中的新应用程序吗？”
It was suggested that the target users for the product be asked their preference. Since the product would be a new generation rewrite of a legacy product, the marketing group agreed to contact a representative sample of current users. Each user in the survey was asked “Would you like our new application in a browser?”
这个问题就像去你最喜欢的餐厅，让服务员问你是否愿意免费用餐。当然，你会的！当然，接受调查的用户回应说，他们希望在浏览器中安装新版本的软件。
This question was like going to your favorite restaurant and having the waiter ask if you’d like to have your meal for free. Of course, you would! And of course the surveyed users responded that they would love to have the new version of the software in a browser.
营销团队犯的错误是他们提出了一个封闭式问题，但没有提供足够的细节来回答。该问题假设任何接受采访的人都知道两者之间的权衡浏览器和未说明的替代品。这个问题的更好版本是：
The mistake the marketing group made was that they asked a closed-ended question and failed to provide sufficient detail for it to be answered. The question assumed that anyone being interviewed would know the tradeoffs between the browser and the unstated alternatives. A better version of the question would have been:
您是否希望我们的新应用程序在浏览器中运行，而不是作为本机 Windows 应用程序运行，即使这意味着性能下降、整体用户体验较差以及交互性降低？
Would you like our new application in a browser rather than as a native Windows application even if it means reduced performance, a poorer overall user experience, and less interactivity?
这道题还是有问题的，因为它是封闭式的。除了简单的“是”或“否”之外，受访者没有任何余地。最好提出开放式问题，让受访者表达更深入的意见。例如，“为了让我们的下一代产品在浏览器中运行，您愿意放弃什么？” 回答该问题的用户可以向多个方向发展。她去哪里——和不去哪里——她的回答将为你提供一个更有意义的问题答案。
This question still has a problem because it is closed-ended. The respondent is given no room for anything other than a simple yes or no. It is far better to ask open-ended questions that let respondents express more in-depth opinions. For example, “What would you be willing to give up in order to have our next generation product run within a browser?” A user answering that question can go in a variety of directions. Where she goes—and does not go—with her answer will provide you with a more meaningful answer to the question.
提出与上下文无关的问题同样重要，这些问题不包含隐含的答案或偏好。例如，您不会问：“您不会愿意为了在浏览器中安装软件而牺牲性能和丰富的用户体验，对吗？” 很明显大多数人将如何回答这个问题。
It is equally important to ask context-free questions, which are ones that do not include an implied answer or preference. For example, you would not ask, “You wouldn’t be willing to trade performance and a rich user experience just for having the software in a browser, would you?” It’s pretty clear how most people are going to answer that question.
同样，不要问“搜索需要多快？” 问“需要什么样的性能？” 或者“性能在应用程序的某些部分更重要吗？” 第一个问题不是上下文无关的，因为它暗示搜索有性能要求。可能没有，但被问到后，用户不太可能这么说；她更有可能猜测。
Similarly, instead of asking “How fast do searches need to be?” ask “What kind of performace is required?” or “Is performance more important in some parts of the application?” The first question is not context-free because it implies there is a performance requirement to searching. There may not have been but, having been asked, a user is unlikely to say so; she’s more likely to take a guess.
在某些时候，您需要从上下文无关的问题转向非常具体的问题。但是，通过从上下文无关的问题开始，您可以为用户提供更广泛的答案。如果您直接跳入非常具体的问题，这将引导您找到可能仍未被发现的故事。
At some point you will need to move from context-free questions to very specific questions. However, by starting with context-free questions you leave open the possibility for a wider range of answers from users. That will lead you to stories that may have remained undiscovered if you jumped right into very specific questions.
调查问卷
Questionnaires
问卷调查是收集已有故事信息的有效方法。如果您有大量用户，那么问卷调查可能是获取有关如何确定故事优先级的信息的好方法。当您需要大量用户对特定问题的回答时，调查问卷同样有用。
Questionnaires can be an effective technique for gathering information about stories you already have. If you have a large user population, then a questionnaire can be a great way to get information about how to prioritize the stories. Questionnaires are similarly useful when you need answers from a large number of users to specific questions.
然而，问卷通常不适合作为搜寻新故事的主要技术。问卷不适合跟进问题。此外，与对话不同，不可能跟随用户沿着出现的有趣路径前进。
However, questionnaires are usually inappropriate as a primary technique of trawling for new stories. Questionnaires do not lend themselves to followup questions. Also, unlike in a conversation, it is impossible to follow a user down an interesting path that comes up.
作为问卷调查的使用示例，您可以调查当前用户，了解他们目前使用软件功能的频率，以及他们不再使用某些功能的原因。这可能会导致某些可用性故事的优先级高于过去的优先级。再举一个例子，一份问卷询问“您希望看到哪些新功能？” 将是有限的用途。如果您给用户一个选择列表，那么您可能会错过您从未想过的五个关键功能。或者，如果允许用户使用自由格式的文本进行回复，则很难将答案制成表格。
As an example use of a questionnaire, you may survey current users about how often they use features in the software today and what their reasons are for not using some feature more. This may lead to prioritizing some usability stories higher than they have been prioritized in the past. As another example, a questionnaire that asked “What new features would you like to see?” will be of limited use. If you give the user a list of choices then you may miss hearing about the five critical features you’ve never thought of. Alternatively, if the user is allowed to respond with free-form text it will be difficult to tabulate answers.
鉴于他们的单向沟通性质和固有的时间滞后，我不建议在拖网故事时使用问卷。如果您想从广泛的现有用户群中收集信息，并且可以等待一个或多个迭代来合并这些信息，那么请以这种方式使用它们，但不要将其作为收集故事的主要方式。
Given their one-way communication nature and inherent time lag, I do not recommend using questionnaires when trawling for stories. If you want to gather information from a broad base of existing users and can wait one or more iterations to incorporate the information, then use them in that manner but not as a primary means of gathering stories.
观察
Observation
观察用户与您的软件的交互是获取见解的绝妙方式。每次我有机会观察某人使用我的软件时，我都会对如何改善他们的体验、生产力或两者兼而有之。不幸的是，除非您是为内部客户开发，否则观察用户的机会很少。太多的商业产品采用了可以猜测用户想要什么的方法。如果您有机会观察用户使用您的软件，请把握机会。这种从用户那里获得快速和直接反馈的机会是尽早和尽可能频繁地发布软件的众多原因之一。
Observing users interact with your software is a wonderful way to pick up insights. Every time I have had the chance to observe someone using my software, I have left flush with ideas about how to improve their experience, productivity, or both. Unfortunately, opportunities for user observation are rare unless you are developing for in-house customers. Too many commercial products take the approach that it’s possible to guess what users want. If you have the chance to observe users work with your software, take it. This chance for rapid and direct feedback from users is one of many reasons to release software as early and often as possible.
在一家公司，用户是在呼叫中心工作的护士。护士们回答了来电者的医疗问题。护士表示他们需要一个大文本字段，可用于在通话结束时记录通话结果。该软件的初始版本在呼叫总结屏幕上包含一个大文本字段。然而，在最初发布后，开发团队的每个成员都花了一天时间观察用户。发现的其中一件事是大文本字段用于输入系统可能已跟踪的内容。通过观察用户，开发人员发现真正需要的是系统跟踪用户在使用软件时做出的决定。大文本字段被替换为记录护士选择的所有搜索和建议的功能。需要——跟踪给呼叫者的所有指令——被护士对需求的描述所掩盖，只有在观察期间才会出现。
At one company the users were nurses working in a call center. The nurses answered medical questions from callers. The nurses indicated that they needed a large text field that could be used for documenting the results of the call when the call was finished. An initial version of the software included a large text field on the call wrapup screen. However, after the initial release each member of the development team spent a day observing the users. One of the things discovered was that the large text field was used for entry of things that could have been tracked by the system. By observing the users, the developers discovered that the real need was for the system to track the decisions made by the user as she worked with the software. The large text field was replaced with a feature that logged all searches and recommendations the nurse selected. The real need—tracking all instructions given to a caller—had been obscured by the nurses’ description of the need and only came out during observation.
故事写作工作坊
Story-Writing Workshops
故事写作研讨会是一个会议，包括开发人员、用户、产品客户和其他可以通过编写故事做出贡献的各方。在研讨会期间，参与者尽可能多地写故事。此时没有优先级与故事相关联；客户稍后将有机会这样做。在我看来，故事写作研讨会是快速搜索故事的最有效方式。至少，我建议在开始每个计划的发布之前举办一个故事写作研讨会。在努力发布的过程中，您始终可以举办额外的研讨会，但这通常是没有必要的。
A story-writing workshop is a meeting that includes developers, users, the product customer and other parties who can contribute by writing stories. During the workshop the participants write as many stories as they can. No priorities are associated with the stories at this point; the customer will have a chance to do that later. In my opinion, a story-writing workshop is the most effective way to quickly trawl for stories. At a minimum, I recommend conducting a story-writing workshop prior to starting each planned release. You can always hold additional workshops while working toward the release but that typically is not necessary.
适当举办的故事写作研讨会可以非常快速地编写大量故事。根据我的经验，一个好的故事写作研讨会将头脑风暴的最佳元素与低保真原型制作相结合。低保真原型是在纸上、笔记卡或白板上完成的，并在计划的软件中映射非常高层次的交互。原型是在研讨会期间迭代构建的，因为参与者集思广益，讨论用户在使用应用程序时可能希望在不同时间点做的事情。这个想法不是像在传统的原型设计或联合应用程序设计 (JAD) 会议中那样识别实际的屏幕和字段。相反，确定了概念性工作流。图 4.1显示了 BigMoneyJobs 网站的低保真原型的开始。
A properly conducted story-writing workshop can be a very rapid way to write a great number of stories. From my experience, a good story-writing workshop combines the best elements of brainstorming with low-fidelity prototyping. A low-fidelity prototype is done on paper, note cards, or a white board and maps very high level interactions within the planned software. The prototype is built up iteratively during the workshop as the participants brainstorm the things a user may want to do at various points while using the application. The idea is not to identify actual screens and fields, as in traditional prototyping or Joint Application Design (JAD) sessions. Rather, the conceptual workflows are identified. Figure 4.1 shows the start of a low-fidelity prototype for the BigMoneyJobs website.
图 4.1。 BigMoneyJobs 的低保真原型。
Figure 4.1. A low-fidelity prototype for BigMoneyJobs.
每个框代表网站的一个新组件。该组件的标题在框中带有下划线。标题下方是一个非常简短的列表，列出了组件的作用或包含的内容。框之间的箭头表示组件之间的链接。对于网站，组件可以是新页面，也可以是当前页面上的空间。因此，链接表示出现新页面或信息显示在同一网页上。例如，搜索职位可能是一个单独的页面，也可能是主页上的一个区域。区别并不重要，因为客户和开发人员稍后将有足够的时间讨论此类细节。
Each box represents a new component of the website. The component’s title is underlined in the box. Below the title is a very short list of what the component does or contains. The arrows between the boxes represent links between the components. For a website, a component may be either a new page or space on the current page. So, a link indicates that a new page appears or that the information is displayed on the same web page. For example, Search Jobs may be a page on its own or it may be an area on the home page. The distinction is not important, as the customer and developers will have plenty of time to discuss specifics like that later.
要开始一个低保真度原型，首先要确定您希望从哪个系统用户角色或角色开始。您将使用每个角色或角色重复该过程，因此顺序无关紧要。接下来，画一个空框，告诉参与者这是软件的主屏幕，并问他们是什么选定的用户角色或角色可以从那里做。即使您还没有弄清楚主屏幕是什么以及该屏幕上有什么活动，也没关系。会议参与者将开始就角色或角色可以采取的行动提出想法。对于每个动作，画一条线到一个新框，标记那个框，然后写一个故事。
To start a low fidelity prototype, first decide which of the system’s user roles or personas you’d like to start with. You’ll repeat the process using each role or persona so the order does not matter. Next, draw an empty box and tell the participants that it is the main screen of the software, and ask them what the selected user role or persona can do from there. It does not matter that you haven’t figured out what the main screen is yet and what’s active on that screen. The meeting participants will start throwing out ideas about what actions the role or persona can take. For each action, draw a line to a new box, label that box, and write a story.
导致创建图 4.1的讨论将产生如下故事：
The discussion that led to the creation of Figure 4.1 will generate stories such as:
- 求职者可以张贴她的简历。
- A Job Seeker can post her resume.
- 雇主可以发布工作。
- An Employer can post jobs.
- 雇主可以审查提交的简历。
- An Employer can review submitted resumes.
- 求职者可以搜索工作。
- A Job Seeker can search for jobs.
- 求职者可以查看与搜索相匹配的工作结果。
- A Job Seeker can view results of jobs that match a search.
- 求职者可以查看有关特定职位的详细信息。
- A Job Seeker can view details about specific jobs.
这些故事都不需要了解屏幕的设计方式。然而，浏览工作流程将帮助所有相关人员尽可能多地思考故事。我发现采用深度优先方法最有效：对于第一个组件，写下它的显着细节，然后移动到连接到第一个的组件并执行相同的操作。然后，移动到连接到那个组件的组件，而不是返回到第一个组件并首先描述连接到它的每个组件。使用广度优先方法可能会让人迷失方向，因为很难记住你在追求每条路径的过程中从哪里停下来。
None of these stories requires knowledge about how the screens will be designed. However, walking through the workflows will help everyone involved think of as many stories as possible. I have found it most efficient to take a depth-first approach: For the first component, write down its salient details, then move to a component connected to the first and do the same. Then, move to a component connected to that one, rather than going back to the first component and first describing each component connected to it. Using a breadth-first approach can be somewhat disorienting as it becomes hard to remember where you left off in pursuing each path to its end.
把它扔掉
务必在创建后几天内丢弃或擦除低保真原型。原型不是您开发过程中的长期产物，您不希望保留它造成任何混淆。如果你带着没有完成的感觉离开故事写作工作坊，那么将原型再保留几天，重新审视它，尝试写下任何遗漏的故事，然后摆脱它。
Be sure to throw away or erase the low-fidelity prototype within a few days of creating it. A prototype is not a long-term artifact of your development process and you don’t want to cause any confusion by keeping it around. If you leave a story-writing workshop with the feeling that you didn’t finish, then keep the prototype around for a few more days, revisit it, try to write any missing stories, and then get rid of it.
低保真原型不需要在您创建它的那一天结束时进入垃圾箱。但它需要尽快结束。
A low-fidelity prototype does not need to go into the trash at the end of the day that you created it. But it needs to end up there soon.
在浏览原型时，提出有助于识别缺失故事的问题，例如：
As you walk through the prototype, ask questions that will help you identify missing stories, such as:
- 用户下一步最有可能想做什么？
- What will the user most likely want to do next?
- 用户可能会在这里犯什么错误？
- What mistakes could the user make here?
- 此时什么会使用户感到困惑？
- What could confuse the user at this point?
- 用户可能需要哪些额外信息？
- What additional information could the user need?
在提出这些问题时，请考虑用户角色和角色。许多答案可能会根据所考虑的用户角色而改变。
Think about the user roles and personas as you ask these questions. Many of the answers can change based on the user role being considered.
维护停车场的问题回来。例如，在讨论 BigMoneyJobs 时，有人可能会问系统是否支持合同工和全职员工。如果在研讨会之前没有人想到这一点，请将其写在某个您可以看到的地方，稍后再回来查看——可以在研讨会结束时，也可以在研讨会结束后的一些后续工作之后。
Maintain a parking lot of issues to come back to. For example, in discussing BigMoneyJobs someone may ask if the system will support contract workers as well as full-time employees. If no one has thought of that prior to the workshop, write it down some place where you can see it and can come back to it later—either at the end of the workshop or after some followup work after the workshop.
在故事写作研讨会期间，重点应该放在数量而不是质量上。即使你最终会以电子方式保存你的故事，在故事写作工作坊使用卡片。让想法来，然后把它们写下来。一个现在看来是个坏主意的故事可能在几个小时后看起来很棒，或者它可能是另一个故事的灵感来源。此外，您不想陷入对每个故事的冗长辩论中。如果一个故事是多余的，或者后来被一个更好的故事所取代，那么你可以撕掉这个故事。同样，当客户对发布的故事进行优先排序时，她可以为低质量的故事分配低优先级。
During a story writing workshop the focus should be on quantity rather than quality. Even if you’ll eventually keep your stories electronically, during the story-writing workshop use cards. Just let the ideas come and write them down. A story that seems like a bad idea now might seem brilliant in a few hours or it may be the inspiration for another story. Additionally, you do not want to get bogged down in lengthy debate over each story. If a story is redundant with or becomes replaced by a better story later, then you can just rip up the story. Similarly, when the customer prioritizes stories for a release, she can assign a low priority to low quality stories.
有时，故事写作研讨会的一些参与者要么难以开始，要么难以突破症结所在。在这种情况下，获得竞争产品或类似产品可能会非常有益。
Occasionally some participants in a story-writing workshop have a hard time either getting started or moving past a sticking point. In this case it can be very beneficial to have access to competitive or similar products.
注意谁在故事写作研讨会上做出了贡献。有时，与会者会在大部分或整个会议期间保持沉默。如果是这种情况，请在其中一次休息期间与参与者交谈，并确保她对这个过程感到满意。一些参与者不愿意在同行或主管面前发言，这就是为什么在这些会议期间不要评判故事创意很重要。一旦参与者对他们的想法只会被记录而不是辩论感到舒服，此时他们将更容易做出贡献。
Pay attention to who is contributing during a story writing workshop. Occasionally a participant will remain silent through much or all of the meeting. If this is the case, talk to the participant during one of the breaks and make sure she’s comfortable with the process. Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is important that story ideas not be judged during these sessions. Once participants become comfortable that their ideas will simply be noted, not debated, at this point they will contribute more readily.
最后，让我重申，用户故事研讨会期间的讨论应该保持在非常高的水平。目标是在尽可能短的时间内编写尽可能多的用户故事。现在不是设计屏幕或解决问题的时候。
Finally, let me reiterate that discussion during a user story workshop should remain at a very high level. The goal is to write as many user stories in as short a time as possible. This is not the time to design screens or solve problems.
概括
Summary
- 引发和捕获需求的想法是错误的。这导致了双重谬误，即用户已经知道所有需求，并且需求可以被捕获并锁在一个笼子里，在那里它们将保持不变。
- The idea of eliciting and capturing requirements is wrong. It leads to the twin fallacies that users already know all the requirements and that requirements can be captured and locked in a cage where they will remain unchanged.
- 需求拖网的比喻要有用得多：它抓住了需求的大小不同、需求可能随时间变化以及找到需求需要技巧的想法。
- The metaphor of trawling for requirements is far more useful: it captures the ideas that there are different sizes of requirements, that requirements may change over time, and that it takes skill to find the requirements.
- 虽然敏捷流程支持流程后期出现的需求，但您仍然应该从期待大约预期发布结束开始，并编写您可以轻松看到的用户故事。
- While agile processes are supportive of requirements that emerge late in the process, you should still start by looking forward to approximately the end of the intended release and write the user stories you can easily see.
- 用户故事可以通过采访用户、观察用户、问卷调查和举办故事写作研讨会来找到。
- User stories can be found by interviewing users, observing users, questionnaires, and holding story-writing workshops.
- 最好的结果是通过使用方法的组合而不是过度依赖任何一种方法来实现的。
- The best results are acheived by using a combination of methods rather than overreliance on any one method.
- 最有用的答案是针对开放式、无关上下文的问题给出的，例如“告诉我你想如何找工作”，而不是“你会按头衔找工作吗？”
- The most useful answers are given in response to open-ended, context-free questions, such as “Tell me about how you’d like to search for a job” rather than “Will you search for a job by title?”
开发者责任
Developer Responsibilities
- 在搜索用户故事时，您有责任理解和使用多种技术。
- You are responsible for understanding and using multiple techniques while trawling for user stories.
- 您有责任了解如何最好地利用开放式和上下文无关的问题。
- You are responsible for knowing how to best make use of open-ended and context-free questions.
客户责任
Customer Responsibilities
- 在搜索用户故事时，您有责任理解和使用多种技术。
- You are responsible for understanding and using multiple techniques while trawling for user stories.
- 您有责任尽早编写尽可能多的用户故事。
- You are responsible for writing as many user stories as early as possible.
- 作为软件用户的主要代表，您有责任了解您在与他们沟通时的选择。
- As the main representative of the software’s users, you are responsible for understanding your options in communicating with them.
- 您有责任了解如何最好地利用开放式和上下文无关的问题。
- You are responsible for knowing how to best make use of open-ended and context-free questions.
- 如果您在撰写故事时需要或想要帮助，您有责任安排和举办一个或多个故事写作研讨会。
- If you need or want help in writing the stories, you are responsible for scheduling and running one or more story-writing workshops.
- 在搜索故事时，您有责任确保所有用户角色都得到适当的代表。
- You are responsible for making sure all user roles are appropriately represented while trawling for stories.
问题
Questions
4.1 如果团队仅通过使用问卷收集需求，您会遇到什么问题？
4.1 What problems would you expect if a team only gathered requirements through the use of questionnaires?
4.2 将以下问题重新表述为上下文无关和开放式的。你认为用户应该输入密码吗？系统是否应该每 15 分钟自动保存一次用户的工作？一个用户可以看到另一个用户保存的数据库条目吗？
4.2 Rephrase the following questions to be context free and open-ended. Do you think the user should have to enter a password? Should the system automatically save the user’s work every 15 minutes? Can one user see database entries saved by another user?
4.3 为什么最好问开放式、无关上下文的问题？
4.3 Why is it best to ask open-ended, context-free questions?
第 5 章使用用户代理
Chapter 5. Working with User Proxies
一个项目在客户团队中包含一个或多个真实用户是至关重要的。虽然其他人可能能够猜测用户希望软件如何运行，但只有真正的用户知道。不幸的是，通常很难获得我们需要的用户。例如，我们可能正在与全国各地的用户一起开发收缩包装产品，但无法将其中一个（或多个）用户带到现场与我们一起撰写故事。或者我们可能正在编写将在我们公司内部使用的软件，但有人告诉我们我们不能与用户交谈。当我们无法获得尽可能多的用户来代表产品的不同观点时，我们需要求助于用户代理，他们可能不是用户本身，但在一个项目中帮助代表用户。
It is vital that a project include one or more real users on the customer team. While others may be able to guess at how a user wants the software to behave, only a real user knows. Unfortunately, it is often difficult to get the users we need. For example, we might be developing a shrinkwrap product with users across the country but be unable to bring one (or more) of them onsite with us to write the stories. Or we might be writing software that will be used within our company, but someone tells us we cannot talk to the users. When we cannot get as many users as we want to represent different perspectives of the product, we need to resort to user proxies, who may not be users themselves but are on a project to help represent users.
选择合适的用户代理对于项目的成功至关重要。必须考虑可能的用户代理的背景和动机。具有营销背景的用户代理处理故事的方式与作为领域专家的用户代理不同。了解这些差异很重要。在本章中，我们将考虑各种用户代理类型，它们有时可能会代替真实用户。
Selection of appropriate user proxies can be critical to the success of the project. The background and motives of possible user proxies must be considered. A user proxy with a marketing background will approach the stories differently than will a user proxy who is a domain expert. It is important to be aware of these differences. In this chapter we will consider various user proxy types who may sometimes fill in for real users.
用户经理
The Users’ Manager
在为供内部使用的项目进行开发时，组织可能不愿意让您完全且不受限制地访问一个或多个用户，但可能愿意让您访问用户经理。除非经理也是该软件的真正用户，否则请将其视为诱饵和转换。即便如此，几乎可以肯定的是，经理的软件使用模式与普通用户不同。例如，在一个呼叫中心应用程序中，团队最初获得了轮班主管的访问权限。虽然轮班主管确实使用了该软件，但他们希望在新版本中获得的许多功能都集中在管理呼叫队列和在座席之间转移呼叫方面。这些功能是对他们监督的用户的重要性非常小，软件主要是为他们设计的。如果开发人员没有推动直接访问更典型的用户，那么产品中监管者不常用的功能就会被过分强调。
When doing development on a project for internal use, the organization may be reluctant to give you full and unlimited access to one or more users but may be willing to give you access to the users’ manager. Consider this a bait-and-switch unless the manager is also a true user of the software. Even then, it is almost certain that the manager has different usage patterns of the software than does a typical user. For example, on one call center application the team was initially given access to shift supervisors. While shift supervisors did use the software, many of the features they wanted in a new version were focused around managing call queues and transferring calls between agents. These features were of very minimal importance to the users they supervised, for whom the software was mostly intended. If the developers had not pushed for direct access to more typical users, the supervisors’ less frequently used features would have been overemphasized in the product.
有时，用户经理会出于自负而调解并希望在项目中扮演用户角色。她可能承认自己不是典型的用户，但会坚持认为她比用户更了解用户的需求。当然，在这种情况下，您需要注意不要冒犯用户的经理。但是你确实需要找到一种方法，至少部分地围绕她和最终用户让项目成功。本章后面第 61 页的“使用用户代理时应该做什么”一节给出了一些想法。
Sometimes the users’ manager intercedes and wants to play the user role on the project because of her ego. She may acknowledge that she’s not a typical user but will insist that she knows more about what her users need than they do. Naturally, though, in this type of situation you will need to be careful not to offend the user’s manager. But you do need to find a way at least partially around her and to the end users for the project to succeed. Some ideas for this are given later in this chapter in the section “What to Do When Working with a User Proxy” on page 61.
五分钟不等于一分钟
这个内部项目的“用户”是一位副总裁，她从未使用过该软件，并且在她和最终用户之间有一定级别的经理。在为下一次迭代确定故事的优先级时，她希望开发人员专注于提高数据库查询的速度。该团队注意到了这个故事及其高度优先级，但他们感到困惑。他们知道应用程序性能至关重要，并在软件中建立了监控机制：每次执行数据库查询时，其参数、执行时间和用户名都会存储在数据库中。这些信息每天至少被监控一次，并且没有出现性能问题的迹象。然而，他们的“用户”告诉他们，一些查询“最多需要五分钟”。
The “user” on this internal project was a Vice President who never used the software and had a level of managers between her and the end users. In prioritizing stories for the next iteration, she wanted the developers to focus on improving the speed of the database queries. The team noted the story and its high priority but they were puzzled. They knew application performance was critical and had built a monitoring mechanism into the software: each time a database query was executed, its parameters, the time it took to execute, and the name of the user were stored in the database. This information was monitored at least once a day and there had been no indications of a performance problem. Yet their “user” had told them that some queries were taking “up to five minutes.”
与副总裁会面后，团队查看了查询执行历史记录。以下是他们的发现：一些用户实际上执行了需要一分钟才能完成的查询。这肯定比预期的要长，但考虑到他们要搜索的内容、数据库的大小以及此类搜索的频率，这在系统的预期性能范围内。但用户已将一分钟查询报告给他们的经理。经理随后将其报告给了副总裁；但为了确保问题引起副总裁的注意，经理说询问需要两分钟时间。然后副总裁将其报告给开发人员，并确保她引起了他们的注意，将问题增加到“最多五分钟”。
After the meeting with the Vice President, the team looked into the query execution history. Here’s what they found: A couple of users had in fact executed queries that took one minute to complete. That was certainly longer than desired but considering what they were searching for, the size of the database, and the infrequency of that type of search, it was within the expected performance of the system. But the users had reported the one-minute query to their manager. The manager then reported it to the Vice President; but to make sure the problem got the Vice President’s attention, the manager said queries were taking two minutes. Then the Vice President reported it to the developers, and to make sure she got their attention, increased the problem to “up to five minutes.”
用户的管理员可能是错误信息的来源。只要有可能，通过与真实用户交谈来证实他们的陈述。
Users’ managers can be sources of misinformation. Whenever possible, corroborate their statements by talking to real users.
开发经理
A Development Manager
开发经理是充当代理用户的最糟糕的选择之一，除非您正在编写针对开发经理的软件。虽然开发经理可能只有最光荣的意图，但她也很可能会有一些相互冲突的目标。例如，开发经理可能会以不同于真实用户的方式对故事进行优先排序，因为这样做可以让她加速引入令人兴奋的新技术。此外，开发经理可能有不一致的公司目标：也许她的年度奖金与项目的完成日期挂钩，这可能导致她认为项目在真正用户之前完成。
A development manager is one of the worst possible choices to act as a proxy user, unless perhaps you are writing software targeted at development managers. While the development manager may have nothing but the most honorable intentions, it is far too likely that she will also have some conflicting goals. For example, the development manager may prioritize stories differently than would a real user because doing so allows her to accelerate the introduction of an exciting, new technology. Additionally, the development manager may have unaligned corporate goals: perhaps her annual bonus is tied to a completion date on the project, which could cause her to consider the project complete before a real user would.
最后，大多数开发经理根本没有作为他们正在构建的软件的用户的实践经验，也不是领域专家。如果你的潜在用户是一位拥有领域专业知识的开发经理，那么在决定你是否有足够的用户代理之前，将她视为领域专家并阅读本章“领域专家”部分的讨论。
Finally, most development managers simply do not have hands-on experience as users of the software they are building and are not domain experts. If your prospective user is a development manager who does have domain expertise, then consider her a domain expert and read the discussion in the “Domain Experts” section of this chapter before deciding if you have an adequate user proxy.
营业员
Salespersons
使用销售人员作为用户代理的危险在于，它不会导致对要构建的产品有一个全面的了解。对销售人员而言，最重要的故事通常是她因缺席而失去最后一笔销售的故事。如果她因为产品没有撤消功能而失去了一笔销售，您可以打赌撤消故事卡将立即被分类到堆的顶部。根据特定销售损失的重要性，可能需要写一两个新故事；然而，过分强调每次销售损失的产品开发公司可能会忘记对产品持有的任何战略和长期愿景。
The danger in using a salesperson as a user proxy is that it does not lead to a comprehensive view of the product to be built. The most important story to a salesperson will usually be the story whose absence cost her the last sale. If she lost a sale because the product does not have an undo feature, you can bet that the undo story card will be instantly sorted right to the top of the pile. Depending on the importance of a specific lost sale, it may be desirable to write a new story or two; however, a product development company that puts too much emphasis on each lost sale may lose track of whatever strategic, long-term vision is held for the product.
然而，销售人员是通向用户的重要渠道，您应该以这种方式使用他们。请他们通过电话或在进行销售访问时将您介绍给客户。更好的是，参加行业贸易展并在贵公司的展览中工作。
Salespeople are, however, a great conduit to users and you should use them in this way. Ask them to introduce you to customers either on the phone or while along on a sales visit. Even better, attend an industry trade show and work in your company’s exhibit.
与您的用户交谈
1995 年，该团队面临创建 Web 上首批综合健康信息网站之一的挑战。因为还没有任何竞争对手，团队无法向他们寻求故事创意。该项目的用户代理是一位具有营销背景的主管。由于他的营销背景，他明白与潜在用户交谈以了解他们在健康信息站点中想要什么的重要性。然而，由于快速交付网站的压力，他只用直觉来指导他向前冲并构建了网站。
In 1995 this team was challenged with creating what would be one of the web’s first general health information sites. Because there were not yet any competitors, the team could not look to them for story ideas. The user proxy for the project was a director with a marketing background. Because of his marketing background, he understood the importance of talking with prospective users to find out what they would want in a health information site. However, because of the pressure to deliver the site quickly, he plunged forward and built the site using only his gut feel to guide him.
您可以猜到，该项目没有满足其用户的需求。网站推出大约一个月后，我走进了营销总监的办公室。他指着他的显示器说：“看那个。看看那个。他的屏幕上是一个色情网站。过了一会儿，我问我们为什么要看它。我认为他甚至没有注意到网站上的色情内容。他的眼睛盯着一个点击计数器，他说：“你看，从昨天开始他们已经有 100,000 次点击了。我们有 200 个。”
As you can guess, the project didn’t fulfill its users’ needs. About a month after the site launched I walked into the marketing director’s office. He pointed to his monitor and said, “Look at that. Just look at that.” On his screen was a porn site. After a moment I asked why we were looking at it. I don’t think he’d even noticed the porn on the site. His eyes were fixed on a hit counter and he said, “Just look, they’ve had 100,000 hits since yesterday. We’ve had 200.”
如果你想让你的软件被使用，你必须与那些将使用它的人交谈。
If you want your software to be used, you have to talk to those who will use it.
领域专家
Domain Experts
领域专家，有时称为主题专家，是关键资源，因为他们非常了解软件将针对的领域。自然地，有些领域比其他领域更难理解。我曾经为律师和律师助理编写过很多软件，虽然这些软件有时很复杂，但我通常都能理解他们的要求。很久以后，我参与了为统计遗传学家编写软件的工作。这个领域充满了表现型、厘摩和单倍型等词。这些是我以前从未听过的词，这使得领域更难掌握。这使得每个开发人员都更加依赖领域专家来帮助我们了解我们正在开发的内容。
Domain experts, sometimes called subject matter experts, are critical resources because of how well they understand the domain the software will be targeted at. Naturally some domains are harder to understand than others. I used to write a lot of software for attorneys and paralegals, and while the software was sometimes complex, I could usually understand what they were asking for. Much later, I was involved with writing software for statistical geneticists. This domain was filled with words like phenotype, centimorgan, and haplotype. These were words I had never heard before, which made the domain much harder to grasp. This made each of the developers much more reliant on a domain expert to help us understand what we were developing.
虽然领域专家是很好的资源，但他们的用处实际上取决于他们是您正在构建的软件类型的当前用户还是以前的用户。例如，在构建薪资系统时，您无疑希望拥有一名注册会计师 (CPA) 作为领域专家。但是，由于用户可能是薪资文员而不是注册会计师，因此您可能会从薪资文员那里获得更好的故事。在构建领域模型和识别业务规则时，领域专家是理想的资源，但工作流和使用问题最好来自实际用户。
While domain experts are great resources, their usefulness is really dependent upon whether they are current or former users of the software type you are building. For example, when building a payroll system you will undoubtedly want to have a Certified Public Accountant (CPA) available as a domain expert. However, since the users will probably be payroll clerks and not CPAs, you will probably get better stories from the payroll clerks. Domain experts are ideal resources when building a domain model and identifying business rules, but workflow and usage issues are better derived from actual users.
使用领域专家作为您的用户代理的另一个潜在问题是，您最终可能会得到仅针对具有相似领域专业知识水平的用户的软件。领域专家可能倾向于将项目指向适合他们但过于复杂或者对于目标用户受众来说完全错误的解决方案。
Another potential problem with using a domain expert as your user proxy is that you may end up with software aimed only at users with similar levels of domain expertise. Domain experts can be inclined to point the project toward a solution that is suitable for them but is too complex or is just plain wrong for the targeted user audience.
营销组
The Marketing Group
Larry Constantine 和 Lucy Lockwood (1999)指出营销团队了解市场而不是用户。这可能导致营销团队或具有营销背景的人更多地关注产品中功能的数量，而不是这些功能的质量。在许多情况下，营销团队可能会提供有关相对优先级的有用的高级指导，但通常没有洞察力来提供有关故事的具体细节。
Larry Constantine and Lucy Lockwood (1999) point out that marketing groups understand markets rather than users. This can lead a marketing group, or someone with a marketing background, to focus more on the quantity of features in the product than on the quality of those features. In many cases a marketing group may provide useful high-level guidance about relative priorities, but often does not have the insight to provide specific details about the stories.
前用户
Former Users
如果前用户的经验是最近的，那么她可以很好地作为代理人。但是，与其他用户代理一样，您应该仔细考虑前用户的目标和动机是否与真实用户的目标和动机完全一致。
A former user can be great as a proxy if her experience is very recent. However, as with other user proxies, you should carefully consider whether the former user’s goals and incentives are fully aligned with those of the real users.
顾客
Customers
顾客是做出购买决定的人；他们不一定是软件的用户。考虑客户的需求很重要，因为他们而不是您的用户才是购买软件的支票。（当然，除非你的用户和客户是同一个人。）
Customers are those who make the buying decision; they are not necessarily users of the software. It is important to consider the desires of your customers because they, not your users, are the ones who write the check to buy the software. (Unless, of course, your users and customers are the same people.)
企业桌面生产力软件是区分客户和用户的完美示例。公司 IT 人员可以决定公司所有员工使用哪种文字处理器。在这种情况下，IT人员是客户，但公司所有员工都是用户（包括既是客户又是用户的IT人员）。此类产品的功能必须足以让用户不会大声尖叫；但这些功能还必须能够吸引做出购买决定的客户。
Corporate desktop productivity software is a perfect example of the distinction between customer and user. The corporate IT staff may decide which word processor is used by all the employees of the company. In this case, the IT staff is the customer but all employees of the company are users (including the IT staff, who are both customer and user). The features in a product like this must be sufficient that the users do not scream too loudly; but the features must also be those that appeal to the customer making the buying decision.
与你的用户交谈 Redux
在一家公司，营销团队作为客户代理服务一种新产品，该产品将取代公司目前的纸质产品。该公司在销售包含医院和保险公司已达成一致的规则的印刷书籍方面取得了非常成功的历史：如果医院遵守规则，他们将由保险公司报销。例如，只有在（除其他外）患者的白细胞计数高于特定阈值时才需要进行阑尾切除术。
In one company the marketing group was serving as a customer proxy for a new product that would replace the company’s current paper-based product. The company had a very successful history selling printed books containing rules that hospitals and insurance companies had agreed upon: if the hospital followed the rules they would be reimbursed by the insurance company. For example, an appendectomy was only called for if (among other things) a patient’s white blood count was above a certain threshold.
营销团队没有兴趣与印刷书籍的用户交谈以了解他们可能希望软件做什么。相反，他们推断他们确切地知道他们的用户想要什么，并且开发可以在营销团队的指导下进行。营销团队为该软件选择了一本书的比喻。他们没有利用软件固有的灵活性，而是选择了一本“自动化书籍”。很明显，用户对该软件感到失望。不幸的是，如果公司使用真实用户而不是营销部门作为用户代理，他们可能很早就知道这一点。
The marketing group had no interest in talking to the users of the printed books to find out what they might want the software to do. Instead they reasoned that they knew exactly what their users would want and development could proceed under the guidance of the marketing group. The marketing group chose a book metaphor for the software. Rather than take advantage of the inherent flexibility of software, they settled for an “automated book.” The users were, quite obviously, disappointed with the software. Unfortunately, the company could have known this very early on if they had used real users rather than a marketing department as a user proxy.
例如，安全功能对于桌面生产力软件的大多数用户来说通常并不重要。然而，对于做出购买决定的 IT 人员（客户）而言，安全性至关重要。
For example, security features are typically unimportant to most users of desktop productivity software. Security is vitally important, however, to the IT staff (the customers) who make the buying decision.
与我合作的一个项目团队设计了一个数据库密集型应用程序。数据将从客户已有的其他系统加载到系统中。开发人员需要指定一种用于交换此数据的文件格式。在这种情况下，客户是组织的 CIO；此功能的用户是其组织中的 IT 人员，他们将编写提取程序以将数据从他们当前的系统移动到新系统指定的格式中。当被问及他对文件格式的偏好时，客户（CIO）认为 XML 是一种理想的技术，因为它在当时相对较新，而且肯定比非标准的逗号分隔值 (CSV) 文件更性感。交付软件时，用户（IT 人员）完全不同意——他们更喜欢生成更简单的 CSV 文件而不是 XML 文件。如果开发团队直接从用户那里得到故事，他们就可以知道这一点，就不会在 XML 格式上浪费时间。
One project team I worked with had designed a database-intensive application. Data would be loaded into the system from other systems the customers already had. The developers needed to specify a file format that would be used to exchange this data. In this case the customer was the CIO of the organization; the users of this functionality were the IT staff in his organization who would write the extract program to move data from their current systems into the format specified for the new system. When asked about his preferences for the file format, the customer (the CIO) decided that XML would be an ideal technology since it was relatively new at the time and was certainly sexier than a non-standard comma-separated value (CSV) file. When the software was delivered, the users (the IT staff) completely disagreed—they would have preferred the much simpler-to-generate CSV file over the XML file. If the development team had got the stories directly from the users, they could have known this and would not have wasted time on the XML format.
培训师和技术支持
Trainers and Technical Support
培训师和技术支持人员作为用户代理人似乎是合乎逻辑的选择。他们每天都在与真实用户交谈，因此他们肯定知道用户想要什么。不幸的是，如果您使用培训师作为您的用户代理，您最终会得到一个易于培训的系统。同样，如果您使用技术支持人员，您最终会得到一个易于支持的系统。例如，来自技术支持的人员可能会将她预计会增加支持工作的高级功能置于低优先级。虽然培训的便利性和可支持性是很好的目标，但它们很可能不是真正的用户会优先考虑的。
Trainers and technical support personnel may seem like logical choices to fill in as a user proxy. They spend their days talking to real users so they must certainly know what users want. Unfortunately, if you use a trainer as your user proxy, you will end up with a system that is easy to train. Similarly, if you use someone from technical support, you will end up with a system that is easily supported. For example, someone from technical support may put low priority on the advanced features that she anticipates will lead to increased support work. While training ease and and supportability are good goals, they are most likely not what a true user would prioritize.
业务或系统分析师
Business or Systems Analysts
许多业务和系统分析师都是很好的用户代理人，因为他们一只脚踏入技术世界，一只脚踏入软件领域。能够平衡这些背景并努力与实际用户交谈的分析师通常是出色的用户代理。
Many business and systems analysts make good user proxies because they have one foot in the technology world and one foot in the domain of the software. An analyst who can balance these backgrounds and who puts effort into talking with actual users is often an excellent user proxy.
一些分析师表现出的一个问题是他们更喜欢思考问题而不是研究问题。我与太多的分析师共事过，他们认为自己可以坐在办公室里，无需与用户实际交谈就可以凭直觉知道用户想要什么。请注意该项目的分析师与用户交谈，并且她不只是自己做决定。
One problem that some analysts exhibit is that they prefer to think about a problem rather than research it. I’ve worked with too many analysts who believe they can sit in their offices and intuit what users will want without actually talking to those users. Be watchful that the project’s analyst talks to users and that she doesn’t just make decisions on her own.
我偶尔遇到的第二个问题是分析师希望在项目的前期活动上花费太多时间。因此，两个小时的角色建模和故事写作研讨会可能足以为延长四个月的发布计划填写细节，一些分析师宁愿花三周时间进行这些活动。
A second problem I’ve occasionally encountered with analysts is a desire to spend too much time in the project’s upfront activities. So, where a two-hour role modeling and story writing workshop might be sufficient to fill in details for a release plan extending out four months, some analysts will prefer to instead spend three weeks on these activities.
使用用户代理时要做什么
What to Do When Working with a User Proxy
虽然不理想，但仍然可以使用用户代理而不是真实用户来编写出色的软件。在这些情况下，您可以应用多种技巧来增加成功的机会。
Although not ideal, it is still possible to write great software with a user proxy rather than a real user. There are a number of techniques you can apply to increase your chances of success in these cases.
当用户存在但访问受限时
When Users Exist But Access Is Limited
如果对真实用户的访问被阻止，而团队被告知通过将做出所有项目决策的用户代理来工作，则团队将需要与代理一起工作，但也需要与实际用户建立联系。执行此操作的最佳技术之一是请求启动用户任务组的许可。用户任务组由任意数量的真实用户组成，从几个到几十个。工作组被用作想法的共鸣板，但代理人仍然是项目的最终决策者。在大多数情况下，代理人会同意这一点，特别是因为它给了她一个安全网来保护她免受错误决定的影响。
If access to real users is blocked and the team is instead told to work through a user proxy who will make all project decisions, the team will need to work with the proxy but also establish a connection to hands-on users. One of the best techniques for doing this is to request permission to start a user task force. A user task force consists of any number of real users, from a handful to a couple of dozen. The task force is used as a sounding-board for ideas, but the proxy remains the project’s final decision-maker. In most cases the proxy will go along with this, especially as it gives her a safety net to protect her against bad decisions.
一旦建立了用户任务组并配备了真正的用户，它通常可以用来指导越来越多的项目日常决策。为此，您可以召开一系列会议来讨论应用程序的各个部分，然后让任务组识别、编写故事并确定故事的优先级。
Once a user task force is established and staffed with real users, it can typically be used to guide more and more of the day–to–day decisions on the project. You can do this by having a series of meetings to discuss parts of the application and then have the task force identify, write, and prioritize stories.
与我合作的一个项目团队正在为内部用户开发一个系统，并通过从用户代理那里获得最高级别的指导、使用原型来展示用户任务组，然后根据用户任务组会议期间产生的反馈采取行动，取得了巨大的成功。这个特定的项目以长达一个月的迭代运行。每次迭代的前几天到一周都花在原型设计和召开一次或多次用户任务组会议上。通过这种方式，用户代理（在本例中为用户经理）可以很好地控制项目的战略方向，但实施细节从她那里移交给了用户任务组。
One project team I worked with was developing a system for internal users and had great success by taking top-level direction from a user proxy, using prototypes to show a user task force, and then acting on feedback generated during user task force meetings. This particular project ran with month-long iterations. The first few days to a week of each iteration was spent prototyping and holding one or more user task force meetings. In this way the user proxy (the users’ manager in this case) had fine control over the strategic direction of the project, but the implementation details were moved from her to the user task force.
当真的没有用户可用时
When There Really Is No User Available
当确实没有可用用户并且您必须求助于用户代理时，一种有价值的技术是使用多个用户代理。这有助于降低构建完全满足个人需求的系统的可能性。使用多个用户代理时，请务必使用不同类型的用户代理。例如，将领域专家与市场营销人员结合起来，而不是使用两个领域专家。您可以通过拥有两个指定的用户代理，或者拥有一个指定的用户代理但鼓励她依赖其他非正式用户代理来做到这一点。
When there really is no user available and you must resort to a user proxy, one valuable technique is to use more than one user proxy. This helps reduce the likelihood of building a system that meets exactly one person’s needs. When using more than one user proxy, be sure to use different types of user proxy. For example, combine a domain expert with someone from marketing rather than using two domain experts. You can do this by either having two designated user proxies, or by having one designated user proxy but encouraging her to rely on other, informal user proxies.
如果您正在开发将与其他商业产品竞争的软件，您可以使用竞争产品作为某些故事的来源。评论中提到了竞争产品的哪些功能？在线新闻组中讨论了哪些功能？是否讨论了这些功能，因为它们使用起来过于复杂？
If you are developing software that will compete with other commercial products, you can use the competing products as a source for some stories. What features in the competing products get mentioned in reviews? What features are discussed in online newsgroups? Are the features discussed because they are overly complex to use?
我记得几年前与一个用例倡导者争论什么类型的文档最能表达系统的需求。他主张采用深思熟虑的用例模型。我赞成用户指南。我从未见过一个项目以完全准确和当前的用例模型结束，尽管有些人已经尝试过了。我见过许多以准确和最新的用户指南作为结尾的项目。如果您正在编写将与现有产品竞争的新软件，您可以通过研究竞争产品学到很多东西。
I remember arguing a few years ago with a use case advocate about what type of document best expresses the requirements of a system. He argued in favor of a well thought-out use case model. I argued in favor of the user’s guide. I have never seen a project that concluded with a perfectly accurate and current use case model even though some have tried. I have seen many projects that conclude with an accurate and current user’s guide. If you are writing new software that will compete with existing products, you can learn a great deal by studying the competing products.
在使用用户代理而不是真实用户时可以使用的另一种技术是尽快发布产品。即使该版本被称为初步或早期测试版，尽早将其交到用户手中也有助于识别您的用户代理和真实用户的想法之间的不一致。更好的是，一旦该软件掌握在一个或多个早期采用者手中，您现在就已经为这些用户开辟了一条沟通渠道，并可以使用它与他们讨论即将推出的功能。
Another technique you can use when working with a user proxy rather than real users is to release the product as soon as possible. Even if the release is called preliminary or an early beta, getting it into the hands of users early will help identify inconsistencies between the thinking of your user proxy and your real users. Even better, once the software is in the hands of one or more early adopters, you have now opened up a communication path to those users and can use that to talk with them about upcoming features.
你能自己做吗？
Can You Do It Yourself?
当您找不到或无法访问真实用户时，请避免陷入自以为了解用户的想法并且不需要或可以忽略您的用户代理的陷阱。虽然每种类型的用户代理都有某种类型的缺点，使她不像真实用户那样令人满意，但大多数开发人员在假装成真实用户时会遇到更多缺点。一般而言，开发人员没有让他们了解功能的相对价值的营销背景，他们没有与销售人员相同数量的客户联系，他们也不是领域专家，等等。
When you cannot find, or get access to, a real user, avoid falling into the trap of thinking you know your users’ minds and do not need or can ignore your user proxy. While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user. In general, developers do not have marketing backgrounds that allow them to understand the relative value of features, they do not have the same amount of customer contact as salespeople, they are not domain experts, and so on.
组建客户团队
Constituting the Customer Team
首先，永远记住真正的用户在任何时候都可以击败代理。尽可能将真实用户置于客户团队中。然而，当您无法获得正确的真实用户组合时，可以使用一个或多个用户代理来补充客户团队。客户团队的构建应该使一个成员的优势能够平衡另一个成员的劣势。创建客户团队有四个步骤。
First, always remember that a real user beats a proxy any time. Whenever possible place real users on the customer team. However, when you can’t get the right mix of real users, supplement the customer team with one or more user proxies. The customer team should be constructed so that the strengths of one member balance the weaknesses of another member. There are four steps in creating a customer team.
首先，添加真实用户。如果该软件由不同类型的用户使用，请尝试包括每种类型的用户。例如，在一个医疗保健应用程序中，我们用户是护士。在我们的客户团队中，我们有普通护士、肿瘤专家、糖尿病专家等用户。
First, add real users. If the software is used by different types of users, try to include a user of each type. For example, on one health care application our users were nurses. On our customer team we had users who were regular nurses, oncology specialists, diabetic specialists, and so on.
其次，确定客户团队中的单个项目拥护者或“同类中的佼佼者”。在商业软件公司中，这通常是产品经理，但也可能是其他人。该项目负责人负责协调客户团队协作。客户团队的所有成员都尽其所能，负责传递一致的信息。虽然可能没有一个客户，但必须有一个客户的声音。
Second, identify a single project champion or “first among equals” on the customer team. In commercial software companies this is very often a product manager, but it could be someone else. This project champion becomes responsible for coordinating customer team collaboration. All members of the customer team are, to the extent they can achieve, responsible for delivering a consistent message. While there may not be one customer, there must be one customer voice.
第三，确定项目成功的关键因素。这将因项目而异。例如，如果项目是创建现有产品的下一代版本，那么关键的成功因素将是现有用户迁移到新系统的难易程度。通过具有相关知识、技能和经验的用户代理来补充客户团队，以解决项目的关键成功因素。在我们将现有用户转移到新系统的示例中，这可能意味着向客户团队添加一名培训师。
Third, determine the factors critical to project success. This will vary from project to project. For example, if the project is to create a next generation version of an existing product, then a critical success factor will be how easily existing users can move to the new system. Supplement the customer team with user proxies with the relevant knowledge, skills, and experience to address the project’s critical success factors. In our example of moving existing users to a new system, this might mean adding a trainer to the customer team.
概括
Summary
- 在本章中，我们了解了不同类型的用户代理，以及为什么在编写用户故事时没有用户代理像真实用户一样理想。
- In this chapter we learned about different types of user proxies and why no user proxy is as ideal as a true user when it comes to writing user stories.
- 用户的经理可能不是合适的用户代理，除非她也是用户。
- The users’ manager may not be an appropriate user proxy unless she is also a user.
- 开发经理制作诱人的用户代理，因为他们已经参与了项目的日常细节。然而，开发经理很少是正在构建的软件的预期用户，因此作为用户代理不是一个好的选择。
- Development managers make tempting user proxies because they are already involved in the day-to-day detail of the project. However, the development manager is rarely an intended user of the software being built and is therefore a poor choice as a user proxy.
- 在产品公司中，客户通常来自营销团队。营销团队的某个人作为用户代理通常是一个不错的选择，但必须克服关注功能数量而不是功能质量的诱惑。
- In product companies, the customer frequently comes from the marketing group. Someone from the marketing group is often a good choice as a user proxy but must overcome the temptation to focus on the quantity rather than quality of features.
- 当销售人员与同时也是用户的各种各样的客户接触时，他们可以成为好的客户。销售人员必须避免将注意力集中在任何可能赢得最后一次失败销售的故事上的诱惑。在所有情况下，销售人员都是与用户沟通的绝佳渠道。
- Salespeople can make good customers when they have contact with a broad variety of customers who are also users. Salespeople must avoid the temptation to focus on whatever story could have won the last lost sale. In all cases, salespeople make excellent conduits to users.
- 领域专家可以成为优秀的用户代理，但必须避免为只有具有专业知识的人才能使用的产品编写故事的诱惑。
- Domain experts can make excellent user proxies but must avoid the temptation to write stories for a product that only someone with their expertise can use.
- 客户，也就是那些做出购买决定的人，如果与他们为其购买软件的用户保持密切沟通，就可以成为很好的用户代理。显然，客户也是用户是一个绝妙的组合。
- Customers, those who make the purchasing decision, can make great user proxies if in close communication with the users for whom they are purchasing the software. Obviously, a customer who is also a user is a fantastic combination.
- 为了成为好的用户代理，培训师和技术支持人员必须避免过于狭隘地关注他们每天看到的产品方面的诱惑。
- In order to be good user proxies, trainers and technical support personnel must avoid the temptation to focus too narrowly on the aspects of the product they see every day.
- 本章还简要介绍了使用用户代理的一些技巧，包括使用用户任务组、使用多个用户代理、竞争分析以及及早发布以获得用户反馈。
- This chapter also looked briefly at some techniques for working with user proxies, including the use of user task forces, using multiple user proxies, competitive analysis, and releasing early to get user feedback.
开发者责任
Developer Responsibilities
- 您有责任帮助您的组织为项目选择合适的客户。
- You have the responsibility to help your organization select the appropriate customer for the project.
- 您有责任了解不同类型的用户代理将如何看待正在构建的系统，以及他们的背景如何影响您的交互。
- You are responsible for understanding how different types of user proxies will think about the system being built and how their backgrounds might influence your interactions.
客户责任
Customer Responsibilities
- 如果您不是该软件的用户，您有责任了解哪些类别的用户代理描述了您。
- If you will not be a user of the software, you are responsible for knowing which categories of user proxy describe you.
- 您有责任了解您可能会给项目带来哪些偏见，并了解如何克服这些偏见，无论是依靠他人还是其他方式。
- You are responsible for understanding what biases you may bring to the project and for knowing how to overcome them, whether by relying on others or some other means.
问题
Questions
5.1 使用用户管理员作为用户的代理会导致什么问题？
5.1 What problems can result from using the users’ manager as a proxy for the users?
5.2 使用领域专家作为用户代理会导致什么问题？
5.2 What problems can result from using a domain expert as a proxy for users?
第 6 章验收测试用户故事
Chapter 6. Acceptance Testing User Stories
编写验收测试的原因之一是要表达客户和开发人员之间对话产生的许多细节。与其编写冗长的“系统应……”样式需求语句列表，不如使用测试来填充用户故事的详细信息。
One reason for writing acceptance tests is to express many of the details that result from the conversations between customers and developers. Rather than writing lengthy lists of “The system shall…” style requirements statements, tests are used to fill in the details of a user story.
最好将测试视为一个两步过程：首先，将有关未来测试的注释记在故事卡的背面。这可以在有人想到新测试时随时进行。其次，测试笔记变成了成熟的测试，用于证明故事已经被正确和完整地编码。
Testing is best viewed as a two-step process: First, notes about future tests are jotted on the back of story cards. This can be done any time someone thinks of a new test. Second, the test notes are turned into full-fledged tests that are used to demonstrate that the story has been been correctly and fully coded.
作为您可能写在卡片背面的测试提醒的示例，“一家公司可以使用信用卡支付职位发布费用”的故事可能在其卡片背面写有以下内容：
As an example of test reminders you may write on the back of a card, the story “A company can pay for a job posting with a credit card” may have the following written on the back of its card:
- 使用 Visa、MasterCard 和 American Express（通过）进行测试。
- Test with Visa, MasterCard and American Express (pass).
- 用 Diner's Club 测试（失败）。
- Test with Diner’s Club (fail).
- 使用好、坏和缺失的卡 ID 号进行测试。
- Test with good, bad and missing card ID numbers.
- 用过期的卡测试。
- Test with expired cards.
- 使用不同的购买金额（包括超过卡限额的金额）进行测试。
- Test with different purchase amounts (including one over the card’s limit).
这些测试说明记录了客户所做的假设。假设 BigMoneyJobs 示例中的客户写了一个故事“求职者可以查看有关特定工作的详细信息”。客户和开发人员讨论这个故事并确定一组将显示的关于职位的事实——头衔、描述、地点、薪水范围、如何申请等等。但是，客户知道并非所有公司都会提供所有这些信息，她希望网站能够处理缺失的数据。例如，如果没有提供薪资信息，客户甚至不希望屏幕上显示“薪资范围”标签。这应该反映为测试，因为程序员可能会假设系统的职位发布部分将要求每个职位发布都包含薪水信息。
These test notes capture assumptions made by the customer. Suppose the customer in the BigMoneyJobs example writes the story “A Job Seeker can view details about a specific job.” The customer and a developer discuss the story and identify a set of facts that will be displayed about a job—title, description, location, salary range, how to apply, and so on. However, the customer knows that not all companies will provide all of this information and she expects the site to handle missing data. For example, if no salary information is provided, the customer does not even want the “Salary range” label shown on the screen. This should be reflected as a test because the programmer may assume that the job posting part of the system will require every job posting to include salary information.
验收测试还提供了可用于确定故事是否已完全实现的基本标准。拥有告诉我们何时完成某事的标准是避免投入过多或过少时间和精力的最佳方式。例如，当我妻子烤蛋糕时，她的验收测试是将牙签插入其中；如果牙签干净了，蛋糕就做好了。我用手指穿过糖霜和品尝来验收测试她的蛋糕。
Acceptance tests also provide basic criteria that can be used to determine if a story is fully implemented. Having criteria that tell us when something is done is the best way to avoid putting too much, or too little, time and effort into it. For example, when my wife bakes a cake, her acceptance test is to stick a toothpick into it; if the toothpick comes out clean, the cake is done. I acceptance test her cake by running a finger through the frosting and tasting.
在编码之前编写测试
Write Tests Before Coding
验收测试提供了大量信息，程序员可以在编写故事之前使用这些信息。例如，考虑“使用不同的购买金额（包括超过卡限额的金额）进行测试”。如果这个测试是在程序员开始编码之前编写的，它会提醒她处理因信用不足而拒绝购买的情况。没有看到那个测试，一些程序员会忘记支持这个案例。
Acceptance tests provide a great deal of information that the programmers can use in advance of coding the story. For example, consider “Test with different purchase amounts (including one over the card’s limit).” If this test is written before a programmer starts coding, it will remind her to handle cases in which a purchase is declined because of insufficient credit. Without seeing that test, some programmers will forget to support this case.
自然地，为了让程序员以这种方式受益，故事的验收测试必须在开始对该故事进行编程之前编写。测试通常在以下时间编写：
Naturally, in order for programmers to benefit in this way, the acceptance tests for a story must be written before programming begins on that story. Tests are generally written at the following times:
- 每当客户和开发人员谈论故事并想要捕获明确的细节时
- whenever the customer and developers talk about the story and want to capture explicit details
- 在迭代开始时作为专门工作的一部分，但在编程开始之前
- as part of a dedicated effort at the start of an iteration but before programming begins
- 每当在故事的编程期间或之后发现新的测试
- whenever new tests are discovered during or after the programming of the story
理想情况下，当客户和开发人员讨论一个故事时，他们将其细节反映为测试。然而，在迭代开始时，客户应该浏览故事并编写她能想到的任何额外测试。做到这一点的一个好方法是查看每个故事并提出类似于以下的问题：
Ideally, as the customer and developers discuss a story they reflect its details as tests. However, at the start of an iteration the customer should go through the stories and write any additional tests she can think of. A good way to do this is to look at each story and ask questions similar to the following:
- 关于这个故事，程序员还需要了解什么？
- What else do the programmers need to know about this story?
- 我假设这个故事将如何实施？
- What am I assuming about how this story will be implemented?
- 这个故事在某些情况下可能会有不同的表现吗？
- Are there circumstances when this story may behave differently?
- 故事中会出现什么问题？
- What can go wrong during the story?
Story Card 6.1展示了一个为扫描系统构建软件的真实项目示例。这个故事的作者已经清楚地说明了她期望发生的事情（新扫描的页面进入一个新文档，即使文档当前在软件中打开）。在这种情况下，期望被描述为卡片正面故事的一部分。它可以像卡背面的测试一样容易地说明。重要的是，在程序员开始讲故事之前，期望就已经反映在卡片上的某个地方。如果不这样做，程序员很可能已经编写了不同的行为代码，例如将新扫描的页面插入到当前文档中。
Story Card 6.1 shows an example for a real project that was buidling software for a scanning system. The author of this story has clearly stated what she expects to happen (the newly-scanned pages go into a new document, even if a document is currently open in the software). In this case, the expectation was described as part of the story on the front of the card. It could just as easily have been stated as a test on the back of the card. The important thing is that the expectation is reflected somewhere on the card prior to the programmers starting on the story. If that is not done, it is likely the programmers could have coded different behavior, such as inserting the newly-scanned pages into the current document.
故事卡 6.1。向程序员传达期望。
Story Card 6.1. Conveying expectations to the programmers.
客户指定测试
The Customer Specifies the Tests
因为软件的编写是为了实现客户的愿景，所以验收测试需要由客户指定。客户可以与程序员或测试人员一起实际创建测试，但客户至少需要指定将用于了解何时正确开发故事的测试。此外，开发团队（尤其是拥有经验丰富的测试人员的团队）通常会用他们想到的测试来扩充一些故事。
Because the software is being written to fulfill a vision held by the customer, the acceptance tests need to be specified by the customer. The customer can work with a programmer or tester to actually create the tests, but minimally the customer needs to specify the tests that will be used to know when a story has been correctly developed. Additionally, a development team (especially one with experienced testers on it) will usually augment some of the stories with tests they think of.
测试是过程的一部分
Testing Is Part of the Process
我最近在一家公司工作，测试人员从程序员那里了解软件。程序员会编写一个新功能，他们会向测试人员解释它，然后测试人员会验证该程序是否按照描述工作。程序通常会通过这些测试，但一旦用户开始使用它，就会被错误所困扰。当然，问题在于测试人员正在测试程序员所做的她说她做了。在没有客户或用户参与的情况下，没有人会测试该软件是否按照他们的意愿进行。
I recently worked with a company where the tester got her understanding of the software from the programmers. The programmers would code a new feature, they’d explain it to the tester, and the tester would then validate that the program worked as described. Quite often the program would pass these tests but would then be plagued with errors once users started working with it. The problem, of course, was that the tester was testing that the programmer did what she said she did. Without involvement from customers or users, no one was testing that the software did what they wanted it to do.
对于用户故事，至关重要的是将测试视为开发过程的一部分，而不是“编码完成后”发生的事情。指定测试通常是产品经理和测试人员的共同责任。产品经理将带来她对推动项目的组织目标的了解；测试人员会带来他的怀疑心态。在迭代开始时，他们将聚集在一起并指定尽可能多的初始测试。但这并不止于此，也不止于他们每周聚会一次。随着故事的细节被制定出来，额外的测试被指定。
With user stories it is vital that testing be viewed as part of the development process, not something that happens “after coding is done.” Specifying tests is often a shared responsibility of a product manager and a tester. The product manager will bring her knowledge of the organizational goals driving the project; the tester will bring his suspicious mindset. At the start of an iteration they will get together and specify as many initial tests as they can think of. But it doesn’t stop there, and it doesn’t stop with them getting together once a week. As the details of a story are worked out, additional tests are specified.
多少测试太多了？
How Many Tests Are Too Many?
客户应该继续编写测试，只要他们为故事增加价值和澄清。如果您已经为过期的 MasterCard 编写了这样的测试，则可能没有必要编写测试来确认不能在过期的 Visa 卡上收费。
The customer should continue to write tests as long as they add value and clarification to the story. It is probably not necessary to write a test to confirm that charges cannot be placed on an expired Visa card if you’ve already written such a test for expired MasterCards.
另外，请记住，一个好的编程团队将对许多低级案例进行单元测试。例如，编程团队应该进行单元测试，将 2 月 30 日和 6 月 31 日正确识别为无效日期。客户不负责识别每一个可能的测试。客户应该集中精力编写测试，向开发人员阐明故事的意图。
Also, keep in mind that a good programming team will have unit tests in place for many of the low-level cases. For example, the programming team should have unit tests that correctly identify February 30 and June 31 as invalid dates. The customer is not responsible for identifying every possible test. The customer should focus her efforts on writing tests that clarify the intent of the story to the developers.
综合测试框架
The Framework for Integrated Test
验收测试旨在证明应用程序可以为负责指导系统开发的客户所接受。这意味着客户应该是执行验收测试的人。至少，验收测试应该在每次迭代结束时执行。因为来自一个迭代的工作代码可能会被后续迭代中的开发破坏，所以从所有先前的迭代中执行验收测试是很重要的。这意味着每次通过迭代执行验收测试都会耗费更多时间。如果可能，开发团队应该考虑使部分或全部验收测试自动化。
Acceptance tests are meant to demonstrate that an application is acceptable to the customer who has been responsible for guiding the system’s development. This means that the customer should be the one to execute the acceptance tests. Minimally, acceptance tests should be executed at the end of each iteration. Because working code from one iteration may be broken by development in a subsequent iteration, it is important to execute acceptance tests from all prior iterations. This means that executing acceptance tests gets more time consuming with each passing iteration. If possible, the development team should look into automating some or all of the acceptance tests.
自动化验收测试的一个优秀工具是 Ward Cunningham 的集成测试框架[1]，简称FIT。使用 FIT，测试被写入熟悉的电子表格或表格格式。Bob 和 Micah Martin 领导了 FitNesse 的开发[2]，FIT 的扩展，使测试编写更加容易。
One excellent tool for automating acceptance tests is Ward Cunningham’s Framework for Integrated Test[1], or FIT for short. Using FIT, tests are written in a familiar spreadsheet or tabular format. Bob and Micah Martin have led the development of FitNesse[2], an extension of FIT that makes test writing even easier.
FitNesse（使用 FIT）正迅速成为一种非常流行的编写敏捷项目验收测试的方法。由于测试是在网页中以类似电子表格的表格表示的，因此大大减少了客户识别和编写测试的工作量。表 6.1是这些工具可以处理的表格类型的示例。每行代表一组数据。在本例中，第一行数据标识一张 2005 年 5 月到期的 Visa 卡，卡号为 4123456789011。最后一列表明这张卡是否应该通过应用程序中的有效性检查。[3]在这种情况下，该卡应被应用程序视为有效。
FitNesse (which uses FIT) is rapidly becoming a very popular approach for writing acceptance tests on agile projects. Because tests are expressed in spreadsheet-like tables within web pages, the effort for customers to identify and write tests is greatly reduced. Table 6.1 is a sample of the type of table that can be processed by these tools. Each row represents one set of data. In this case the first data row identifies a Visa card that expires in May of 2005 and has the number 4123456789011. The final column indicates whether this card should pass a validity check in the application.[3] In this case the card is expected to be considered valid by the application.
表 6.1。 使用 FIT 和 FitNesse 可以使用的表格测试有效信用卡。
Table 6.1. Testing for valid credit cards with a table that can be used by FIT and FitNesse.
为了执行表 6.1中的测试，团队中的一名程序员需要编写代码来响应简单的 FIT 命令。她编写的代码调用正在测试的应用程序中的代码以确定信用卡的有效性。但是，要编写验收测试，客户只需创建一个像这样的简单表格来显示数据值和预期结果。
In order to execute the tests in Table 6.1, a programmer on the team needs to write code to respond to simple FIT commands. She writes code that invokes code in the application being tested to determine the validity of the credit card. However, to write the acceptance tests, the customer only needs to create a simple table like this one that shows data values and expected results.
运行表 6.1中的测试时，通过将测试列（本例中的最后一列）着色为绿色（表示通过测试）或红色（表示测试失败）来显示结果。FitNesse 和 FIT 使客户或开发人员运行验收测试变得简单。
When the tests in Table 6.1 are run, the results are displayed by coloring the test columns (the last column in this example) either green (for a passed test) or red (for a failed test). FitNesse and FIT make it simple for either a customer or developer to run the acceptance tests.
测试类型
Types of Testing
测试有多种类型，客户和开发团队应共同努力以确保进行适当类型的测试。对于大多数系统，故事测试主要是功能测试，它确保应用程序按预期运行。但是，还有其他类型的测试需要考虑。例如，您可能需要考虑以下任何或所有内容：
There are many types of testing, and the customer and development team should work together to ensure that the appropriate types of testing are occurring. For most systems, story testing is largely functional testing, which ensures that the applicaton functions as expected. There are, however, other types of testing to be considered. For example, you may want to consider any or all of the following:
- 用户界面测试，确保用户界面的所有组件都按预期运行
- User interface testing, which ensures that all of the components of the user interface behave as expected
- 可用性测试，这是为了确保可以轻松使用的应用程序
- Usability testing, which is done to ensure an application that can be easily used
- 性能测试，用于衡量应用程序在各种工作负载下的性能
- Performance testing, which is done to gauge how well the application will perform under various workloads
- 压力测试，其中应用程序受到用户、事务或任何其他可能使应用程序承受压力的极端值的影响
- Stress testing, in which the application is subjected to extreme values of users, transactions, or anything else that may put the application under stress
测试错误，而不是覆盖率
在一个敏捷的、故事驱动的项目中，测试对于许多团队来说并不是对抗性的活动。当发现错误时，不会有“我明白了”的心态。当错误一直蔓延到生产环境时，就没有推卸责任的余地了。团队的高度协作，我们都在这一起的心态可以防止这种情况发生。
On an agile, story-driven project, testing is not the antagonistic activity that it becomes for many teams. There is no “I gotcha” mentality when a bug is found. There is no room for passing the blame when a bug makes it all the way to production. The highly-collaborative, we’re–all–in–this–together mentality of the team prevents this.
在敏捷项目中，我们通过测试来发现和消除错误；我们不一定追求 100% 代码覆盖率或测试所有边界条件的目标。我们使用我们的直觉、我们的知识和我们过去的经验来指导我们的测试工作。
On an agile project, we test to find and eliminate bugs; we don’t necessarily pursue goals of 100% code coverage or testing of all boundary conditions. We use our intuition, our knowledge, and our past experience to guide our test effort.
测试由最有能力进行测试的人完成。客户需要指定验收测试，但她是在开发人员和专门测试人员的帮助和信息的帮助下完成的。例如，考虑表 6.1中的测试。唯一经过测试的过期卡是万事达卡。如果我们力求全面覆盖，我们还需要测试其他卡片类型。但是，当客户与开发人员交谈时，她了解到（在本例中）所有卡的处理方式相同，测试一种类型的无效卡就足够了。随着时间的推移，通过频繁的交流和查看哪些类型的测试失败了，项目中的每个人都学会了如何最好地集中测试工作。
Testing is done by whoever is best equipped to do the testing. A customer needs to specify the acceptance tests but she does that with assistance and information from the developers and dedicated testers. For example, consider the tests in Table 6.1. The only expired card that is tested is a MasterCard. If we were striving for complete coverage we would also need to test other card types. But when the customer speaks with the developers, she learns that (in this example) all cards are processed identically and testing an invalid card of one type is sufficient. Over time, through frequent communication and through seeing which types of tests fail, everyone on the project learns how best to focus the test effort.
概括
Summary
- 验收测试用于表达客户和开发人员之间的对话产生的细节。
- Acceptance tests are used to express details that result from conversations between a customer and a developer.
- 验收测试记录了关于客户可能没有与开发人员讨论过的故事的假设。
- Acceptance tests document assumptions about the story a customer has that may not have been discussed with a developer.
- 验收测试提供了可用于确定故事是否已完全实现的基本标准。
- Acceptance tests provide basic criteria that can be used to determine if a story is fully implemented.
- 验收测试应该由客户而不是开发人员编写。
- Acceptance tests should be written by the customer rather than by a developer.
- 验收测试是在程序员开始编码之前编写的。
- Acceptance tests are written before the programmer begins coding.
- 当额外的测试无助于阐明故事的细节或意图时，停止编写测试。
- Stop writing tests when additional tests will not help clarify the details or intent of the story.
- FIT 和 FitNesse 是用熟悉的表格或电子表格格式编写验收测试的优秀工具。
- FIT and FitNesse are excellent tools for writing acceptance tests in a familiar table or spreadsheet format.
开发者责任
Developer Responsibilities
- 如果您的团队选择这样做，您可能负责自动执行验收测试。
- You may be responsible for automating the execution of acceptance tests if your team chooses to do so.
- 当您开始开发新故事时，您有责任考虑额外的验收测试。
- You are responsible for thinking about additional acceptance tests when you start development of a new story.
- 您负责对您的代码进行单元测试，这样就不需要为故事的所有细节指定验收测试。
- You are responsible for unit testing your code so that acceptance tests do not need to be specified for all the minutiae of a story.
客户责任
Customer Responsibilities
- 您负责编写验收测试。
- You are responsible for writing the acceptance tests.
- 您负责执行验收测试。
- You are responsible for executing the acceptance tests.
问题
Questions
6.1 谁指定测试？谁帮忙？
6.1 Who specifies the tests? Who helps?
6.2 为什么在故事编码之前指定测试？
6.2 Why specify tests before the stories are coded?
第 7 章好故事的指导方针
Chapter 7. Guidelines for Good Stories
在这一点上，在了解什么是故事、如何搜索和编写故事、如何识别关键用户角色以及验收测试的作用等方面有了良好的基础后，我们将注意力转向编写好故事的一些额外指南。
At this point, with a good foundation of what stories are, how to trawl for and write them, how to identify key user roles, and the role of acceptance testing, we turn our attention to some additional guidelines for writing good stories.
从目标故事开始
Start with Goal Stories
在大型项目中，尤其是具有许多用户角色的项目中，有时甚至很难知道从哪里开始识别故事。我发现最有效的方法是考虑每个用户角色并确定用户与我们的软件交互的目标。例如，请考虑 BigMoneyJobs 示例中的求职者角色。她确实有一个首要目标：找一份工作。但我们可以认为该目标包括以下目标：
On a large project, especially one with many user roles, it is sometimes difficult to even know where to begin in identifying stories. What I’ve found works best is to consider each user role and identify the goals that user has for interacting with our software. For example, consider the Job Seeker role in the BigMoneyJobs example. She really has one top priority goal: find a job. But we may consider that goal to comprise the following goals:
- 搜索她感兴趣的工作（根据技能、薪水、地点等）
- search for jobs she’s interested in (based on skill, salary, location, and so on)
- 使搜索过程自动化，这样她就不必每次都手动搜索
- automate the search process so she doesn’t have to search manually each time
- 提供她的简历，以便公司可以搜索她
- make her resume available so that companies may search for her
- 轻松申请她喜欢的任何工作
- easily apply for any jobs she likes
然后可以根据需要使用这些目标（它们本身实际上是高级故事）来生成其他故事。
These goals (which really are high-level stories themselves) can then be used to generate additional stories as needed.
切蛋糕
Slice the Cake
当面对一个大故事时，通常有很多方法可以将它分解成更小的部分。许多开发人员的第一个倾向是拆分故事沿着技术路线。例如，假设团队决定“A Job Seeker can post a resume”的故事太大，无法放入当前迭代中，必须拆分。开发人员可能希望沿着技术边界拆分它，例如：
When faced with a large story, there are normally many ways of breaking it into smaller pieces. The first inclination of many developers is to split the story along technical lines. For example, suppose the team has decided that the story “A Job Seeker can post a resume” is simply too large to fit in the current iteration and must be split. The developers may want to split it along technical boundaries, such as:
- 求职者可以填写简历表。
- A Job Seeker can fill out a resume form.
- 简历表上的信息被写入数据库。
- Information on a resume form is written to the database.
在这种情况下，一个故事将在当前迭代中完成，而另一个故事将推迟到（大概）下一次迭代。这样做的问题是，这两个故事本身对用户来说都不是很有用。第一个故事说求职者可以填写表格，但不会保存数据。这不仅没有用，而且实际上会浪费用户的时间。第二个故事说表单上收集的数据将写入数据库。如果没有一个故事来向用户呈现表单，第二个故事就没有用。
In this case, one story would be done in the current iteration while the other story would be deferred until (presumably) the next iteration. The problem with this is that neither story on its own is very useful to users. The first story says that job seekers can fill out a form but that the data is not saved. Not only is this not useful, it would actually waste users’ time. The second story says that the data collected on the form will be written to the database. Without a story to present the form to users, the second story is not useful.
一种更好的方法是编写替换故事，使每个故事都提供某种程度的端到端功能。Bill Wake (2003a) 将此称为“切蛋糕”。每个故事必须从每一层都有一点。这导致拆分“求职者可以发布简历”，如下所示：
A far better approach is to write the replacement stories such that each provides some level of end–to–end functionality. Bill Wake (2003a) refers to this as “slicing the cake.” Each story must have a little from each layer. This leads to splitting “A Job Seeker can post a resume” like this:
- 求职者可以提交一份仅包含姓名、地址、教育经历等基本信息的简历。
- A Job Seeker can submit a resume that includes only basic information such as name, address, education history.
- 求职者可以提交一份简历，其中包含雇主可能希望看到的所有信息。
- A Job Seeker can submit a resume that includes all information an employer may want to see.
代表整块蛋糕的故事比那些不代表的故事更受欢迎。有两个原因。首先，对应用程序体系结构的每一层进行测试可以降低在其中一层发现最后一刻问题的风险。其次，虽然不理想，但可以想象，只要包含在发布切片中的功能贯穿整个系统，就可以仅使用部分功能发布应用程序。
Stories that represent a full slice of cake are to be preferred over those that do not. There are two reasons for this. First, exercising each layer of an application’s architecture reduces the risk of finding last minute problems in one of the layers. Second, although not ideal, an application could conceivably be released for use with only partial functionality as long as the functionality that is included in the release slices all the way through the system.
写封闭的故事
Write Closed Stories
Soren Lauesen (2002)在他的需求技术纲要中介绍了任务关闭的概念。他的想法同样适用于用户故事。一个封闭的故事是一个以实现一个有意义的目标而结束的故事，它让用户觉得她已经完成了一些事情。
Soren Lauesen (2002) introduces the idea of closure for tasks in his compendium of requirements techniques. His ideas are equally applicable to user stories. A closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished something.
例如，假设 BigMoneyJobs 网站项目包含故事“招聘人员可以管理她投放的广告”。这不是一个封闭的故事：管理她放置的广告并不是一件完全可以完成的事情。相反，这是一项持续的活动。这个故事可以更好地构建为一组封闭的故事，例如：
For example, suppose the BigMoneyJobs website project includes the story “A recruiter can manage the ads she has placed.” This is not a closed story: Managing the ads she’s placed is not something that is ever completely done. Instead, it is an ongoing activity. This story can be better constructed as a set of closed stories, such as:
- 招聘人员可以在她的一个广告中查看求职者的简历。
- A recruiter can review resumes from applicants to one of her ads.
- 招聘人员可以更改广告的到期日期。
- A recruiter can change the expiration date of an ad.
- 招聘人员可以删除与工作不匹配的申请。
- A recruiter can delete an application that is not a good match for a job.
等等。这些关闭的故事中的每一个都是原始故事中未关闭的部分。完成其中一个封闭故事后，用户可能会感到成就感。
And so on. Each of these closed stories is a part of the original story that was not closed. After completing one of these closed stories, a user is likely to feel a sense of accomplishment.
写封闭故事的愿望必须根据相互竞争的需求来调节。请记住，故事还需要足够小以便进行估算，并且足够小以便方便地安排到单个迭代中。但故事也必须足够大，这样您就可以避免在必要时过早地捕获有关它们的细节。
The desire to write closed stories has to be tempered against competing needs. Remember that stories also need to be small enough to be estimatable and small enough to be conveniently scheduled into a single iteration. But stories must also be large enough that you avoid capturing details about them any earlier than necessary.
对卡片施加约束
Put Constraints on Cards
Newkirk 和 Martin (2001)推荐了一种我发现有用的做法。他们介绍了为任何必须遵守而不是直接实施的故事在故事卡上标注“约束”的做法。可以在Story Card 7.1中看到一个示例。
Newkirk and Martin (2001) recommend a practice I’ve found useful. They introduce the practice of annotating a story card with “Constraint” for any story that must be obeyed rather than directly implemented. An example can be seen in Story Card 7.1.
故事卡 7.1。约束故事卡的示例。
Story Card 7.1. An example of a constraint story card.
约束的其他例子是：
Other examples of constraints are:
- 如果以后需要，不要让软件国际化变得困难。
- Do not make it hard to internationalize the software if needed later.
- 新系统必须使用我们现有的订单数据库。
- The new system must use our existing order database.
- 该软件必须在所有版本的 Windows 上运行。
- The software must run on all versions of Windows.
- 该系统将实现 99.999% 的正常运行时间。
- The system will achieve uptime of 99.999%.
- 该软件将易于使用。
- The software will be easy to use.
尽管约束卡不像普通卡那样被估计和安排到迭代中，但它们仍然有用。至少，限制卡可以贴在墙上，作为提醒。更好的是，可以编写验收测试以确保不违反约束。例如，为Story Card 7.1编写测试并不困难。理想情况下，团队会在第一次迭代中的一次迭代中编写此测试，此时它被违反的可能性很小。然后，团队将继续运行测试，作为每个后续迭代的一部分。只要有可能（通常是这样），编写自动化测试以确保满足约束条件。
Even though constraint cards do not get estimated and scheduled into iterations like normal cards, they are still useful. Minimally, constraint cards can be taped to the wall where they act as reminders. Even better, acceptance tests can be written to ensure the constraint is not violated. For example, it would not be difficult to write a test for Story Card 7.1. Ideally the team would write this test during one of the first iterations when there’s little chance of it being violated. The team would then continue running the test as part of each subsequent iteration. Whenever possible (and it usually is), write automated tests to ensure that constraints are being met.
有关约束作为指定非功能性需求的一种方式的更多信息，请参阅第 16 章“其他主题”。
For more on constraints as a way of specifying nonfunctional requirements see Chapter 16, “Additional Topics.”
将故事调整到地平线
Size the Story to the Horizon
您希望将注意力集中在最需要的领域。通常，这意味着更多地关注近期发生的事情，而不是更远的事情。对于故事，您可以根据故事的实施范围编写不同级别的故事。这意味着，例如，接下来几次迭代的故事将按照可以规划到这些迭代中的大小编写，而更远的故事可能更大且更不精确。例如，假设在最高级别我们确定 BigMoneyJobs 网站将包含四个故事：
You want to focus your attention on the areas that most need it. Usually, this means paying more attention to things happening in the near future than to things happening further out. With stories, you do this by writing stories at different levels based on the implementation horizon of the stories. This means, for example, that stories for the next few iterations would be written at sizes that can be planned into those iterations, while more distant stories could be much larger and less precise. For example, suppose at the highest level we’ve determined that the BigMoneyJobs website will include four stories:
- 求职者可以发布简历。
- A Job Seeker can post a resume.
- 求职者可以搜索职位空缺。
- A Job Seeker can search job openings.
- 招聘人员可以发布职位空缺。
- A Recruiter can post a job opening.
- 招聘人员可以搜索简历。
- A Recruiter can search resumes.
客户已决定第一次迭代将侧重于允许用户发布简历。只有在添加了大部分简历发布功能后，注意力才会转向搜索工作、发布职位空缺和搜索简历。这意味着项目团队和客户将开始就“求职者可以发布简历”进行对话。随着通过这些对话发现细节，这个故事将得到扩展；其他三个高层故事将保持不变。然后可能的故事列表变为：
The customer has decided that the first iterations will focus on allowing users to post resumes. Only after the bulk of the resume posting functionality has been added will attention be turned to searching for jobs, posting job openings, and searching resumes. This means that the project team and customer will start having the conversations about “A Job Seeker can post a resume.” That story will be expanded as details are discovered through those conversations; the other three high-level stories will be left alone. A possible list of stories then becomes:
- 求职者可以向网站添加新的简历。
- A Job Seeker can add a new resume to the site.
- 求职者可以编辑网站上已有的简历。
- A Job Seeker can edit a resume that is already on the site.
- 求职者可以从网站上删除她的简历。
- A Job Seeker can remove her resume from the site.
- 求职者可以将简历标记为无效。
- A Job Seeker can mark a resume as inactive.
- 求职者可以将简历标记为对某些雇主隐藏。
- A Job Seeker can mark a resume as hidden from certain employers.
- 求职者可以看到她的简历被浏览了多少次。
- A Job Seeker can see how many times her resume has been viewed.
- ……等等关于发布简历……
- … and so on about posting resumes…
- 求职者可以搜索职位空缺。
- A Job Seeker can search job openings.
- 招聘人员可以发布职位空缺。
- A Recruiter can post job openings.
- 招聘人员可以搜索简历。
- A Recruiter can search resumes.
在编写您的故事时，利用故事的灵活性以在各个层面发挥作用。
In writing your stories, take advantage of the flexibility of stories to be useful at various levels.
尽可能长时间地保留 UI
Keep the UI Out as Long as Possible
困扰每种软件需求方法的问题之一是将需求与解决方案规范混合在一起。也就是说，在陈述需求时，解决方案也被明确陈述或暗示。这种情况最常发生在用户界面的各个方面。您希望尽可能长时间地让用户界面远离您的故事。例如，考虑Story Card 7.2，这是一个来自真实系统的故事。如果这个故事要在项目生命周期的早期开发，它包含了太多的用户界面细节。这个故事的读者被告知打印对话框、打印机列表和至少四种搜索方式。
One of the problems that has plagued every approach to software requirements has been mixing requirements with solution specification. That is, in stating a requirement, a solution is also either explicitly stated or implied. Most commonly this happens with aspects of the user interface. You want to keep the user interface out of your stories as long as possible. For example, consider Story Card 7.2, which is a story from a real system. If this story is to be developed early in the life of the project, it includes too many user interface details. Readers of this story are told about the print dialog, printer lists, and at least four ways of searching.
最终，用户界面细节将不可避免地融入故事中。随着软件变得越来越完整，故事从全新功能转变为对现有功能的修改或扩展，就会发生这种情况。
Eventually it will become inevitable for user interface details to slip into stories. This happens as the software becomes more and more complete, and stories shift away from being entirely new functionality to being modifications or extensions of existing functionality.
例如，考虑“用户可以从搜索屏幕上的日期小部件中选择日期”这样的故事。这个故事可能代表三天的工作，无论无论是在项目开始还是结束时完成。但是，这不是您在项目开始时甚至还没有考虑用户界面之前就期望的故事。
For example, consider the story “A user can select dates from a date widget on the search screen.” This story may represent three days of work regardless of whether it’s done at the start or end of the project. However, it is not a story you’d expect to have at the start of the project before the user interface has even been considered.
故事卡 7.2。具有过多用户界面细节的卡片。
Story Card 7.2. A card with too much user interface detail.
有些事情不是故事
Some Things Aren’t Stories
虽然用户故事是一种非常灵活的格式，可以很好地描述许多系统的大部分功能，但它们并不适合所有情况。如果您需要以用户故事以外的形式表达一些需求，那就这样做吧。例如，用户界面指南通常在包含大量屏幕截图的文档中进行描述。同样，除了任何用户故事之外，您可能还想记录重要系统之间的接口并就此达成一致，尤其是当外部供应商正在开发一个接口时。
While user stories are a very flexible format that works well for describing much of the functionality of many systems, they are not appropriate for everything. If you need to express some requirements in a form other than user stories, then do so. For example, user interface guidelines are often described in documents with lots of screen captures. Similarly, apart from any user stories, you may want to document and agree upon an interface between important systems, especially if one is being developed by an external vendor.
如果您发现系统的某些方面可以从不同格式的表达中获益，那么就使用该格式。
If you find that some aspect of a system could benefit from expression in a different format, then use that format.
在故事中包含用户角色
Include User Roles in the Stories
如果项目团队已经确定了用户角色，他们应该在编写故事时使用它们。因此，他们没有写“用户可以发布她的简历”，而是写“求职者可以发布她的简历”。差异很小，但以这种方式编写故事可以让用户始终处于开发人员的首要位置。开发人员不再考虑乏味的、不露面的、可互换的用户，而是开始考虑真正的、有形的用户，她需要用软件来满足这些用户。
If the project team has identified user roles, they should make use of them in writing the stories. So instead of writing “A user can post her resume” they write “A Job Seeker can post her resume.” The difference is minor but writing stories in this way keeps the user in the forefront of the developer’s mind. Instead of thinking of bland, faceless, interchangeable users, the developer will begin thinking of real, tangible users whom she needs to satisfy with the software.
Connextra 是极限编程的早期采用者之一，它通过使用一个简短的模板将角色融入到他们的故事中。每个故事都按以下格式编写：
Connextra, one of the early adopters of Extreme Programming, incorporated roles into their stories by using a short template. Each story was written in the following format:
我作为一个（角色）想要（功能）以便（商业价值）
I as a (role) want (function) so that (business value)
您可能想尝试使用此模板或您自己的模板。像这样的模板可以帮助区分重要故事和琐碎故事。
You may want to experiment with this template or with one of your own. A template like this can help distinguish important from frivolous stories.
为一个用户写
Write for One User
为单个用户编写的故事通常最具可读性。对于许多故事，为一个或多个用户编写不会有什么不同。但是，对于某些故事，差异可能很大。例如，考虑“求职者可以从网站上删除简历”这个故事。这可以解释为一个求职者可以删除她自己的简历，也可能删除其他人的简历。
Stories are generally most readable when written for a single user. For many stories, writing for one or many users will not make a difference. However, for some stories the difference can be significant. For example, consider the story “Job Seekers can remove resumes from the site.” This could be interpreted to mean that one Job Seeker can remove her own resume and possibly the resumes of others.
通常，当您在考虑单个用户的故事时，此类问题会变得很清楚。例如，上面的故事可以写成“A Job Seeker can remove resumes”。这样写的话，一个求职者删除别人简历的问题就更加明显了，故事可以进一步改进为“一个求职者可以删除自己的简历”。
Normally, this type of issue will become clear when you think about a story with a single user in mind. For example, the story above could be written as “A Job Seeker can remove resumes.” When written this way, the problem of one Job Seeker removing resumes of others becomes more apparent, though, and the story can be further improved to “A Job Seeker can remove her own resumes.”
用主动语态书写
Write in Active Voice
用主动语态书写时，用户故事更容易阅读和理解。例如，与其说“求职者可以发布简历”，不如说“求职者可以发布简历”。
User stories are easier to read and understand when written in active voice. For example, rather than saying “A resume can be posted by a Job Seeker” say “A Job Seeker can post a resume.”
客户写
Customer Writes
理想情况下，客户编写故事。在许多项目中，开发人员会提供帮助，或者通过在最初的故事写作研讨会上进行实际写作，或者通过向客户推荐新故事。但是，编写故事的责任在于客户，不能转给开发人员。
Ideally the customer writes the stories. On many projects the developers help out, either by doing the actual writing during an initial story writing workshop or by suggesting new stories to the customer. But, responsibility for writing stories resides with the customer and cannot be passed to the developers.
此外，由于客户负责确定将进入每个迭代的故事的优先级，因此客户理解每个故事至关重要。做到这一点的最好方法是编写它们。
Additionally, because the customer is responsible for prioritizing the stories that will go into each iteration, it is vital that the customer understand each story. The best way to do this is to write them.
不要给故事卡编号
Don’t Number Story Cards
第一次使用故事卡时，我们中的许多人都想给它们编号。通常的推理是，这将有助于跟踪单个卡片或为故事添加一定程度的可追溯性。例如，当我们发现卡片 13 上的故事太大时，我们会撕掉卡片 13 并用卡片 13.1、13.2 和 13.3 替换它。然而，给故事卡编号会给流程增加毫无意义的开销，并导致我们对需要有形的功能进行抽象讨论。我宁愿谈论“添加用户组的故事”而不是“故事 13”。我特别不想谈论“故事 13.1”。
The first time we use story cards many of us are tempted to number them. The usual reasoning is that this will help keep track of individual cards or add some level of traceability to stories. For example, when we discover that the story on card 13 is too large we rip up card 13 and replace it with cards 13.1, 13.2, and 13.3. However, numbering story cards adds pointless overhead to the process and leads us into abstract discussions about features that need to be tangible. I’d rather talk about “the story to add user groups” than “story 13.” I especially don’t want to talk about “story 13.1.”
如果您觉得有必要给故事卡片编号，请尝试为卡片添加一个简短的标题，并使用该标题作为故事文本其余部分的简写。
If you feel compelled to number story cards, instead try adding a short title to the card and use the title as shorthand for the rest of the story text.
不要忘记目的
Don’t Forget the Purpose
不要忘记，故事卡片的主要目的是提醒人们讨论该功能。保持这些提醒简短。添加您需要记住从何处继续对话的详细信息，但不要通过向故事卡添加更多详细信息来替换对话。
Don’t forget that the main purpose of a story card is to act as a reminder to discuss the feature. Keep these reminders brief. Add the detail you need to remember where to resume a conversation, but do not replace the conversation by adding more detail to the story card.
概括
Summary
- 要识别故事，首先要考虑每个用户角色在使用系统时的目标。
- To identify stories, start by considering the goals of each user role in using the system.
- 拆分故事时，请尝试提出贯穿应用程序所有层的故事。
- When splitting a story, try to come up with stories that cut through all layers of the application.
- 尝试编写故事的大小，让用户在完成故事后觉得有理由喝杯咖啡休息一下。
- Try to write stories that are of a size where the user feels justified in taking a coffee break after completing the story.
- 根据项目领域和环境的需要，使用其他需求收集或记录技术来扩充故事。
- Augment stories with other requirements gathering or documenting techniques as necessary for the project’s domain and environment.
- 创建约束卡并将它们贴在共享墙上或编写测试以确保不违反约束。
- Create constraint cards and either tape them to a shared wall or write tests to ensure the constraints are not violated.
- 为团队即将实施的功能编写较小的故事，并为更远的将来的功能编写广泛的、高层次的故事。
- Write smaller stories for functionality the team will implement soon, and write broad, high-level stories for functonality further into the future.
- 尽可能长时间地让用户界面远离故事。
- Keep the user interface out of the stories for as long as possible.
- 在可行的情况下，在编写故事时包括用户角色。
- When practical, include the user role when writing the story.
- 用主动语态写故事。例如，说“求职者可以发布简历”而不是“求职者可以发布简历”。
- Write stories in active voice. For example, say “A Job Seeker can post a resume” rather than “A resume can be posted by a Job Seeker.”
- 为单个用户编写故事。将“求职者可以删除简历”改为“求职者可以删除自己的简历”。
- Write stories for a single user. Instead of “Job Seekers can remove resumes” write “A Job Seeker can remove her own resumes.”
- 让客户而不是开发人员来编写故事。
- Have the customer, rather than a developer, write the stories.
- 保持用户故事简短，并且不要忘记它们作为保持对话的提醒的目的。
- Keep user stories short, and don’t forget their purpose as reminders to hold conversations.
- 不要给故事卡编号。
- Don’t number story cards.
问题
Questions
7.1 假设“求职者可以搜索空缺职位”这个故事太大，无法放入一次迭代中。你会如何拆分它？
7.1 Assume the story “A Job Seeker can search for open jobs” is too large to fit into one iteration. How would you split it?
7.2 以下哪个故事的大小合适并且可以被认为是一个封闭的故事？
7.2 Which of these stories is appropriately sized and can be considered a closed story?
一种。用户可以保存她的偏好。
a. A user can save her preferences.
b. 用户可以更改用于购买的默认信用卡。
b. A user can change the default credit card used for purchases.
C。用户可以登录系统。
c. A user can log on to the system.
7.3 哪些简单的改变可以改善“用户可以发布简历”的故事？
7.3 What simple changes could improve the story “Users can post their resumes”?
7.4 你将如何测试“软件将易于使用”的约束条件？
7.4 How would you test the constraint “The software will be easy to use”?
第二部分：估算和规划
Part II: Estimating and Planning
通过了解我们集体腰带下的故事，我们可以将注意力转向使用用户故事来估算和规划项目。在几乎所有项目中，我们都需要或被要求提供项目所需时间的估计。需要准备营销活动，需要培训用户，需要购买硬件等等。这些活动中的每一项都取决于项目的计划。
With an understanding of stories under our collective belts, we can turn our attention to estimating and planning projects with user stories. On almost all projects, we need, or are asked, to provide an estimate of how long the project will take. Marketing campaigns need to be readied, users need to be trained, hardware needs to be purchased and so on. Each of these activities depends upon a project’s plans.
在第 II 部分中，我们将了解如何估算故事以及如何为交付最高优先级故事创建高级发布计划。然后我们将看到如何在每次迭代开始时使用额外的细节完善发布计划，以及执行该迭代工作所需的额外计划。最后，我们将研究衡量和监控项目进度的方法，以便我们可以不断调整计划以反映我们从每次迭代中获得的知识。
In Part II, we will see how to estimate the stories and how to create a high-level release plan for delivery of the highest priority stories. Then we’ll see how the release plan is refined with additional detail at the start of each iteration with the additional planning necessary to perform the work of that iteration. Finally, we’ll look at ways to measure and monitor the progress of the project so that we can constantly adjust the plan to reflect the knowledge we gain from each iteration.
第 8 章估算用户故事
Chapter 8. Estimating User Stories
在有人开始问“你什么时候完成？”之前，任何项目都不会持续很长时间。估计故事的最佳方法是：
No project can go very long before someone starts asking “When will you be done?” The best approach for estimating stories would be one that:
- 每当我们有关于故事的新信息时，允许我们改变主意
- allows us to change our mind whenever we have new information about a story
- 适用于史诗和较小的故事
- works for both epics and smaller stories
- 不需要很多时间
- doesn’t take a lot of time
- 提供有关我们的进展和剩余工作的有用信息
- provides useful information about our progress and the work remaining
- 容忍估计中的不精确
- is tolerant of imprecision in the estimates
- 可用于计划发布
- can be used to plan releases
故事点
Story Points
满足其中每一个目标的方法是估计故事点。故事点的一个很好的特点是每个团队都按照他们认为合适的方式来定义它们。一个团队可能决定将故事点定义为理想的工作日（即没有任何干扰的一天——没有会议、没有电子邮件、没有电话等等）。另一个团队可能将故事点定义为理想的一周工作时间。还有一个团队可能将故事点定义为故事复杂性的度量。由于故事点的含义多种多样，Joshua Kerievsky 建议故事点代表 Nebulous Units of Time，或 NUT。[1]
An approach that satisfies each of these goals is to estimate in story points. A nice feature of story points is that each team defines them as they see fit. One team may decide to define a story point as an ideal day of work (that is, a day without any interruptions whatsoever—no meetings, no email, no phone calls, and so on). Another team may define a story point as an ideal week of work. Yet another team may define a story point as a measure of the complexity of the story. Because of the wide variety of meanings for story points, Joshua Kerievsky has suggested that story points represent Nebulous Units of Time, or NUTs.[1]
我的偏好是将故事点视为理想的工作日。我们很少有这些理想的日子，但在理想的时间思考故事有两个好处。首先，它比估计经过的时间更容易。估算经过的时间迫使我们考虑所有其他可能对我们的时间产生的影响，例如周二的全公司会议、周三我的牙医预约、每天回复电子邮件的几个小时等等。其次，与在完全模糊的单位中估计故事点相比，在理想时间中估计故事点为我们的估计提供了稍微更好的基础。由于估算的主要目的之一是能够回答有关项目总体预期工作量的问题，因此我们最终需要将估算值转换为时间。从理想时间开始，比从完全模糊的单位开始，转换要简单一些。
My preference is to treat a story point as an ideal day of work. We rarely have these ideal days, but thinking about stories in ideal time offers two advantages. First, it is easier than estimating in elapsed time. Estimating in elapsed time forces us to consider all other possible impacts on our time, such as the all-company meeting on Tuesday, my dentist appointment on Wednesday, a few hours a day for answering email, and so on. Second, estimating story points in ideal time gives our estimates a slightly better foundation than when they are estimated in entirely nebulous units. Since one of the main purposes of estimating is to be able to answer questions about the overall expected effort in a project, we will eventually need to convert estimates into time. Starting with ideal time makes that conversion a little simpler than starting with an entirely nebulous unit.
估计作为一个团队
Estimate as a Team
故事估算需要由团队共同拥有。稍后，在第 10 章“计划迭代”中，我们将看到一个故事包含多个任务，并且任务估计由将执行该任务的个人拥有。然而，故事估算归团队所有，原因有二：首先，由于团队还不知道谁将处理故事，故事的所有权不能比分配给团队更精确。其次，团队而非个人得出的估计可能更有用。
Story estimates need to be owned collectively by the team. Later, in Chapter 10, “Planning an Iteration,” we’ll see that a story comprises multiple tasks and that a task estimate is owned by the individual who will perform the task. Story estimates, however, are owned by the team for two reasons: First, since the team doesn’t yet know who will work on the story, ownership of the story cannot be more precisely assigned than to the team collectively. Second, estimates derived by the team, rather than a single individual, are probably more useful.
由于故事估算归团队所有，因此让合理比例的团队成员参与估算非常重要。如果团队很大（可能有七人或更多），并不是每个开发人员都需要参与，但通常参与的开发人员越多越好。客户在程序员估算时参与，但不允许她提供个人估算或在听到她不赞成的估算时发表社论。
Since story estimates are owned by the team it is important to have a reasonable portion of the team involved in coming up with the estimates. If the team is large (perhaps seven or more), not every developer needs to be involved, but generally the more developers involved the better. The customer participates while the programmers estimate, but she isn’t allowed to contribute her personal estimates or editorialize when she hears an estimate she disapproves of.
估计
Estimating
我首选的估计方法源自 Boehm (1981) 记录的宽带 Delphi 方法。就像极限编程是一种开发软件的迭代方法一样，我们将用于估算的方法也是一种开发估算的迭代方法。它是这样工作的：
My preferred estimation approach is derived from the Wideband Delphi approach documented by Boehm (1981). Just like Extreme Programming is an iterative approach to developing software, the approach we’ll use to estimating is an iterative approach to developing estimates. Here’s how it works:
首先，将参与创建估算的客户和开发人员聚集在一起。带上故事卡和一叠额外的空白记事卡。（即使您以电子方式维护故事描述，也请带上一些空白卡片。）向每位参与者分发一把空白卡片。客户从集合中随机选择一个故事并将其读给开发人员听。开发人员根据需要提出尽可能多的问题，客户会尽其所能回答这些问题。如果她不知道答案，她会猜测或要求团队推迟估计这个故事。
First, gather together the customer and the developers who will participate in creating the estimates. Bring along the story cards and a stack of additional blank note cards. (Bring some blank cards even if you’re maintaining the story descriptions electronically.) Distribute a handful of blank cards to each participant. The customer selects a story at random from the collection and reads it to the developers. The developers ask as many questions as they need and the customer answers them to the best of her ability. If she doesn’t know the answer, she takes a guess or asks the team to defer estimating that story.
一切都需要四个小时
我最喜欢的电视节目之一是Mad About You，讲述一对住在纽约的新婚夫妇的故事。在一集中，丈夫（Paul Reiser）被妻子（Helen Hunt）缠着去买沙发。她坚称这次旅行只需要一个小时。他告诉她，“世界上的一切都需要四个小时。你必须去那里，你必须做任何事情，吃东西，讨论你应该在哪里吃东西，然后回家。最少四个小时。”
One of my favorite television shows was Mad About You, which is about a recently married couple living in New York. In one episode the husband (Paul Reiser) is being pestered by his wife (Helen Hunt) to go shopping for a couch. She insists the trip will take only an hour. He tells her that “Everything in the world takes four hours. You gotta go there, you gotta do whatever, eat, talk about where you should have eaten, and then come home. That’s four hours minimum.”
当程序员估算故事时，他们应该包括完成故事所需要做的一切。他们需要考虑诸如测试代码、与客户交谈、可能帮助客户计划或自动化验收测试等因素。如果他们不包括这些活动，就好像他们期望购买一张沙发只需要一个小时。
When the programmers estimate a story, they should include everything they’ll need to do to complete the story. They need to factor in such things as testing their code, talking to the customer, perhaps helping the customer plan or automate acceptance tests, and so on. If they don’t include these activities, it is like they are expecting shopping for a couch to take only an hour.
当没有关于这个故事的更多问题时，每个开发人员在卡片上写下一个估计，但还没有向其他人展示估计。如果团队将故事点定义为理想工作日，开发人员会考虑完成故事需要多少理想天数。相反，如果团队将故事点定义为故事的复杂性，那么估计就是故事的感知复杂性。
When there are no more questions about the story, each developer writes an estimate on a card, not yet showing the estimate to the others. If the team has defined a story point as a day of ideal work, the developers think about how many ideal days the story will take to complete. If, instead, the team has defined a story point as, for example, the complexity of the story then the estimate is of the perceived complexity of the story.
当每个人都写完估算后，估算员将他们的卡片翻过来或举起来让每个人都能看到。在这一点上，估计值很可能会有很大差异。这其实是个好消息。如果估计值不同，高估计值和低估计值会解释他们的估计。重要的是，这不会给人留下攻击那些估算器的印象。相反，您想了解他们在想什么。
When everyone has finished writing an estimate, the estimators turn over their cards or hold them up so everyone can see them. It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates. It’s important that this does not come across as attacking those estimators. Rather, you want to learn what it is they were thinking about.
例如，高估者可能会说，“好吧，为了测试这个故事，我们需要创建一个模拟数据库对象，这可能需要我们一天的时间。此外，我不确定我们的标准压缩算法是否有效，我们可能需要编写一种内存效率更高的算法。” 低估价者可能会回应说，“我在想我们会把这些信息存储在一个 XML 文件中——这比数据库更容易。另外，我没想过需要更多数据——也许这会成为一个问题。”
As an example, the high estimator may say, “Well, to test this story we’re going to need to create a mock database object and that might take us a day. Also, I’m not sure if our standard compression algorithm will work and we may need to write one that is more memory efficient.” The low estimator may respond with, “I was thinking we’d store that information in an XML file—that would be easier than a database. Also, I didn’t think about needing more data—maybe that will be a problem.”
此时，小组最多讨论几分钟。毫无疑问，其他估算者会对高估值者和低估值者处于极端的任何原因发表意见。客户在问题出现时澄清问题。可以在故事卡上记下一两个注释。也许写了一两个新故事。
At this point the group discusses it for up to a few minutes. Other estimators will undoubtedly have opinions on whatever reasons the high and low estimators were at the extremes. The customer clarifies issues as they come up. A note or two may be jotted on the story card. Perhaps a new story or two is written.
在小组讨论完故事后，开发人员再次将他们的估计写在卡片上。当每个人都写下修改后的估算后，卡片再次显示。在许多情况下，估计值将在第二轮之前收敛。但是，如果他们没有，请重复让高估值者和低估值者解释他们估值背后的想法的过程。在许多情况下，高估值和低估值与第一轮不同。事实上，我有时会看到高估者和低估者在讨论中获得新知识后走向相反极端的情况。
After the group has discussed the story, the developers again write their estimates on cards. When everyone has written a revised estimate, the cards are again displayed. In many cases the estimates will already converge by the second round. But, if they have not, repeat the process of having the high and low estimators explain the thinking behind their estimates. In many cases the high and low estimators will not be the same as in the first round. In fact, I have sometimes seen cases where the high and low estimators went to opposite extremes after gaining new knowledge during the discussion.
目标是让估算器收敛于可用于故事的单个估算值。它很少需要超过三轮，但只要估计越来越接近，就继续这个过程。没有必要让房间里的每个人都交出一张写有完全相同估算值的卡片。如果我参与估算会议，并且在第二轮四位估算员告诉我 4、4、4 和 3 个故事点，我将询问低估算员她是否接受四天的估算。关键是合理性，而不是绝对的精确性。是的，开发人员可能会谈得更久，并就三四个故事点达成共识，但花在这上面的时间是不值得的。
The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together. It isn’t necessary that everyone in the room turn over a card with exactly the same estimate written down. If I’m involved in an estimation meeting, and on the second round four estimators tell me 4, 4, 4, and 3 story points, I will ask the low estimator if she is OK with a four day estimate. The point is reasonableness not absolute precision. Yes, the developers could probably talk longer and reach consensus on three or four story points, but the time spent doing so isn’t worth it.
三角剖分
Triangulate
在做出最初的几个估计之后，就可以（并且有必要）对估计进行三角测量。三角测量估计是指根据故事与一个或多个其他故事的关系来估计故事。假设一个故事被估计为四个故事点。第二个故事估计有两个故事点。当两个故事一起考虑时，程序员应该同意四点故事的大小大约是两点故事的两倍。然后，当他们将一个故事估计为三点时，他们应该同意它大致大于两点故事但小于四点故事。
After the first few estimates have been made, it becomes possible (and necessary) to triangulate the estimates. Triangulating an estimate refers to estimating a story based on its relationship to one or more other stories. Suppose a story is estimated at four story points. A second story is estimated at two story points. When the two stories are considered together the programmers should agree that the four-point story is roughly twice the size of the two-point story. Then, when they estimate a story as being three points, they should agree that it is roughly larger than the two-point story yet smaller than the four-point story.
这些都不是准确的，但三角测量是团队验证他们没有逐渐改变故事点含义的有效方法。三角测量的一个好方法是根据故事卡的大小将它们固定在墙上。在墙上画垂直线，用故事点数标记每一列，然后将故事卡片别在墙上相应的列中，如图 8.1所示。在估算每个新故事时，将其固定在适当的位置。很快将新估计的故事与专栏中的其他故事进行比较，看看它是否“大致相同”。
None of this is exact, but triangulation is an effective means for a team to verify that they aren’t gradually altering the meaning of a story point. A good way to triangulate is to pin story cards to the wall based on their size. Draw vertical lines on the wall, label each column with the number of story points, and then pin story cards to the wall in the appropriate column, as shown in Figure 8.1. As each new story is estimated, pin it in the appropriate location. Very quickly compare the newly-estimated story to others in the column to see if it is “about the same.”
图 8.1。 将故事卡钉在墙上以促进三角测量。
Figure 8.1. Pin story cards to the wall to facilitate triangulation.
使用故事点
Using Story Points
在迭代结束时，团队计算他们完成的故事点数。然后，他们使用它来预测在即将到来的相同长度的迭代中他们将完成多少故事点。例如，假设一个团队在两周的迭代中完成了 32 个故事点。我们最好的猜测是他们还将在下一次迭代中完成 32 个故事点。我们使用术语速度来指代团队在一次迭代中完成（或期望完成）的故事点数。
At the end of an iteration the team counts the number of story points they completed. They then use that as a forecast of how many story points they’ll complete in upcoming iterations of the same length. For example, suppose a team completes 32 story points over a two-week iteration. Our best guess is that they’ll also complete 32 story points in the next iteration. We use the term velocity to refer to the number of story points a team completes (or expects to complete) in an iteration.
让我们看看速度和故事点是如何协同工作的，以及为什么准确性不重要。假设一个团队正在开始一个新项目。他们估算了该项目的所有故事，并提出了总共三百个故事点。在第一次迭代开始之前，他们预计他们每周可以共同完成 30 个故事点，这意味着该项目将需要十次迭代（周）。
Let’s look at how velocity and story points work together and why accuracy isn’t important. Suppose a team is starting a new project. They estimate all of the stories for the project and come up with a total of three hundred story points. Before the start of the first iteration they project that collectively they can complete thirty story points per week, which means the project will take ten iterations (weeks).
在第一次迭代结束时，团队将他们完成的故事的故事点相加。他们发现他们完成了 50 个故事点而不是完成 30 个故事点。如果他们可以在每次迭代中完成 50 个故事点，他们将在总共 6 次迭代中完成项目。他们是否应该计划保持 50 的测量速度？是的，他们应该，基于三个条件。
At the end of the first iteration the team adds up the story points for the stories they completed. They find that rather than completing 30, they completed 50 story points. If they can complete 50 story points in each iteration, they will finish the project in a total of six iterations. Should they plan on maintaining their measured velocity of 50? Yes, they should, based on three conditions.
首先，没有什么不寻常的（比如大量加班、额外的程序员等）影响了这次迭代的生产力。加班或其他生产力的影响速度的因素是显而易见的。如果一次迭代的速度是基于每个人每周工作 60 小时，那么如果他们恢复每周工作 40 小时，那么下一次迭代的速度将会大幅下降。
First, nothing unusual (like a bunch of overtime, an extra programmer, or so on) affected productivity this iteration. The impact of overtime or other productivity factors on velocity is obvious. If velocity of one iteration is based on everyone working sixty-hour weeks, there will be a big drop in velocity in the next iteration if they return to working forty hour weeks.
其次，估计需要以一致的方式生成。这很重要，因为它可以消除从一次迭代到下一次迭代的速度波动。假设在一次迭代中，团队只处理仅由臭名昭著的高估者估计的故事。如果后来迭代中的故事是由具有不同偏见的人估计的，那么团队在该迭代中的速度会人为地高。确保估计一致的最佳方法是使用本章中描述的团队估计过程。
Second, the estimates need to have been generated in a consistent manner. This is important because it evens out fluctuations in velocity from one iteration to the next. Suppose in one iteration the team worked on nothing but stories that had been estimated only by a notorious overestimator. The team’s velocity for that iteration would be artificially high if stories in later iterations were estimated by someone with a different bias. The best way to ensure that estimates are consistent is to use a team estimation process as described in this chapter.
最后，为第一次迭代选择的故事必须是独立的。如果故事是按照第 2 章“写故事”中建议的方式编写的，就会出现这种情况。考虑一个完全由构造不佳的故事组成的迭代，这样迭代期间的所有工作都在用户界面上。我们不想将该迭代的速度外推到所有剩余的迭代上。
Finally, the stories selected for the first iteration must be independent. This will be the case if stories were written in the manner suggested in Chapter 2, “Writing Stories.” Consider an iteration comprised entirely of poorly constructed stories such that all work during the iteration is on the user interface. We would not want to extrapolate the velocity of that iteration onto all remaining iterations.
为什么这有效
中心极限定理告诉我们，来自任何分布的多个独立样本的总和近似服从正态分布。
The Central Limit Theorem tells us that the sum of a number of independent samples from any distribution is approximately normally distributed.
就我们的目的而言，这意味着团队的故事点估计可能会偏向低估、高估或以任何其他方式分布。但是当我们从任何这些分布中获取一个迭代的故事价值时，我们获取的故事将呈正态分布。这意味着我们可以使用一次迭代的测量速度来预测未来迭代的速度。
For our purposes, this means that a team’s story point estimates can be skewed way toward underestimation, way toward overestimation, or distributed in any other way. But when we grab an iteration’s worth of stories from any of those distributions, the stories we grab will be nomally distributed. This means that we can use the measured velocity of one iteration to predict the velocity of future iterations.
自然地，一次迭代的速度并不是一个完美的预测器。例如，包含一个 20 点故事而不是 20 个 1 点故事的迭代将是一个不太准确的预测器。同样，随着团队学习新技术、新领域或习惯新的团队成员或新的工作方式，速度可能会发生变化。
Naturally, the velocity of one iteration is not a perfect predictor. For example, an iteration containing one twenty-point story rather than twenty one-point stories would be a less accurate predictor. Similarly, velocity may change as a team learns new technology, a new domain, or becomes accustomed to new team members or new ways of working.
如果我们配对程序怎么办？
What If We Pair Program?
团队是否选择配对程序对故事点估计没有影响。例如，假设一个有两个开发人员的团队正在根据理想的工作日估计故事点。它们不是结对编程。他们计划进行为期一周的迭代，其中包括两个故事，每个故事估计有三个故事点。在迭代期间，他们完成了这两个故事，并将他们的团队速度计算为 6。
Whether or not a team chooses to pair program has no effect on story point estimates. For example, suppose a team with two developers is estimating in story points that are based on ideal days of work. They are not pair programming. They plan a one-week iteration that will include two stories, each estimated at three story points. During the iteration they finish those two stories and calculate their team velocity as six.
相反，假设他们结对编程，并且他们估计在理想的结对日内。他们查看这些故事并决定每个故事都需要两个理想的配对日。在为期一周的迭代结束时，他们完成了两个故事并计算出他们的速度为 4。
Suppose instead that they pair program and that they estimate in ideal pair days. They look at the stories and decide that each will take two ideal pair days. At the end of the one-week iteration they have completed both stories and calculate their velocity as four.
虽然用不同的数字表示，但这两种情况下的速度是相同的。这两个团队以相同的速度前进，因为他们在迭代中完成了相同数量的工作。这意味着团队可以选择在理想的结对日或理想的个人程序员日来估算故事点，任何差异都会反映在速度上。
While represented by different numbers, the velocities in these two cases are the same. The two teams are moving at the same speed since they completed the same amount of work in their iterations. This means that a team can choose to estimate story points in ideal pair days or ideal individual programmer days, and any differences will be reflected in the velocity.
精确度随着故事大小的增加而降低
估计故事点的一个问题是一些数字之间的差异很难证明是合理的。例如，假设开发人员正在考虑一个故事，并且一位开发人员建议该故事值得两个故事点。另一个反驳说这个故事是三个故事点。这个讨论是有道理的：三个故事点代表比两个故事点多 50% 的工作。两个开发人员很有可能讨论一个故事并争论如此巨大的差异。
A problem with estimating in story points is that differences between some numbers can be hard to justify. For example, suppose the developers are considering a story and one developer suggests that the story is worth two story points. Another counters that the story is three story points. This discusson makes sense: three story points represents 50% more work than two story points. It’s very possible for two developers to discuss a story and argue about differences of that magnitude.
然而，现在假设开发人员正在争论一个故事应该是七个还是八个故事点。在大多数情况下，如此大的数字之间的一分差异太小而无法讨论任何相关性。争论一个故事是否值得七个或八个故事点意味着我们的估计过程比我们现在更精确。
However, now suppose the developers are arguing over whether a story should be seven or eight story points. In most cases a one point difference between numbers that large is too small to be discussed with any relevance. Arguing about whether a story is worth seven or eight story points implies more precision in our estimation process than we have.
为了避免这种情况并简化事情，团队可能希望同意将估计值限制为特定的预定义值，例如：
To avoid this situation and simplify things, the team may want to agree to constrain estimates to specific pre-defined values such as:
½, 1, 2, 3, 5, 8, 13, 20, 40, 80
½, 1, 2, 3, 5, 8, 13, 20, 40, 80
这很吸引人，因为它反映了这样一个事实：随着估计值越来越大，我们对它们的了解越来越少。如果团队要考虑史诗，他们将不得不决定是 40 分还是 80 分，但他们不必考虑是 79 分还是 80 分。
This is appealing because it reflects the truth that as estimates get larger, we know less about them. If the team has an epic to consider they’ll have to decide whether it’s a 40 or an 80, but they won’t have to think about whether it’s a 79 or an 80.
一些提醒
Some Reminders
使用故事点有时会令人困惑。这通常是由于对故事点考虑太多或试图使它们超过他们是。要强化使用故事点的方式，请牢记以下事实：
Working with story points can sometimes be confusing. Usually this results from thinking too hard about story points or trying to make them more than they are. To reinforce the ways you can use story points, keep these facts in mind:
- 你团队的故事点数不等于我团队的故事点数。你的团队估计值三个故事点的故事对我的团队来说可能值五个。
- Your team’s story points are not equivalent to my team’s story points. A story your team estimates as worth three story points may be worth five to my team.
- 当一个故事（可能是一个史诗）被分解成它的组成故事时，各个故事的估计总和不需要等于初始故事或史诗的估计。
- When a story (possibly an epic) is disaggregated into its constituent stories, the sum of the estimates for the individual stories does not need to equal the estimate of the initial story or epic.
- 类似地，故事可以分解为组成任务。任务的估计总和不需要等于初始故事的估计。
- Similarly, a story may be disaggregated into constituent tasks. The sum of the estimates for the tasks does not need to equal the estimate of the initial story.
概括
Summary
- 按故事点估算故事，故事点是对故事的复杂性、工作量或持续时间的相对估计。
- Estimate stories in story points, which are relative estimates of the complexity, effort or duration of a story.
- 估算故事需要由团队来完成，并且估算归团队而不是个人所有。
- Estimating stories needs to be done by the team, and the estimates are owned by the team rather than individuals.
- 通过将估计值与其他估计值进行比较来对估计值进行三角测量。
- Triangulate an estimate by comparing it to other estimates.
- 团队是否成对编程对故事点估计没有影响。结对编程影响团队的速度，而不是他们的估计。
- Whether or not a team programs in pairs has no impact on story point estimates. Pair programming affects the team’s velocity, not their estimates.
开发者责任
Developer Responsibilities
- 您有责任以您的团队相关且可用的方式定义故事点。您有责任始终坚持该定义。
- You are responsible for defining story points in a manner that is relevant and usable by your team. You are responsible for consistently sticking to that definition.
- 您有责任提供诚实的估计。您有责任不屈服于低估的诱惑或压力。
- You are responsible for giving honest estimates. You are responsible for not giving in to temptation or pressure to give low estimates.
- 您有责任作为一个团队进行估算。
- You are responsible for estimating as a team.
- 您有责任提供与其他估计一致的估计。也就是说，所有的两点故事应该是相似的。
- You are responsible for giving estimates that are consistent with other estimates. That is, all the two-point stories should be similar.
客户责任
Customer Responsibilities
- 你负责参加估算会议，但你的角色是回答问题和澄清故事。不允许您自己估算故事。
- You are responsible for participating in estimation meetings, but your role is to answer questions and clarify stories. You are not allowed to estimate stories yourself.
问题
Questions
8.1 在估算会议期间，三个程序员正在估算一个故事。他们分别在两个、四个和五个故事点上估计故事。他们应该使用哪种估计？
8.1 During an estimating meeting three programmers are estimating a story. Individually they estimate the story at two, four and five story points. Which estimate should they use?
8.2 三角测量估计的目的是什么？
8.2 What is the purpose of triangulating estimates?
8.3 定义速度。
8.3 Define velocity.
8.4 A 队在最后两周的迭代中完成了 43 个故事点。团队 B 正在从事一个单独的项目，并且拥有两倍的开发人员。他们还在最后两周的迭代中完成了 43 个故事点。这个怎么可能？
8.4 Team A finished 43 story points in their last two-week iteration. Team B is working on a separate project and has twice as many developers. They also completed 43 story points in their last two-week iteration. How can that be?
第 9 章计划发布
Chapter 9. Planning a Release
大多数软件项目最好每两到六个月发布一次新版本。某些网站项目可能会更频繁地发布，但即便如此，将相关的新功能收集到一个版本中也是有好处的。从产品开发路线图开始发布计划通常很有用，该路线图显示了下几个新版本的主要关注领域。这个产品开发路线图肯定会改变——我们希望它改变，因为改变将是我们对我们的产品、它的市场和我们开发产品的能力有了更多了解的结果。
Most software projects will do best with a new release every two to six months. Certain website projects may release even more frequently, but even then there is a benefit to collecting related new features into a release. It is frequently useful to start release planning from a product development roadmap showing the main areas of focus for the next handful of new releases. This product development roadmap will certainly change—and we want it to since the changes will be the result of our learning more about our product, its market, and our ability to develop the product.
产品开发路线图可以很简单，只列出主要关注领域，或Kent Beck 所说的主题，用于接下来的几个版本中的每一个。例如，对于 BigBucksJobs.com 网站的下一个版本，我们可能会列出以下主题：
A product development roadmap can be as simple as a list of the main areas of focus, or themes as Kent Beck calls them, for each of the next few releases. For example, for the next release of the BigBucksJobs.com website we may list the following themes:
- 企业简历筛选筛选工具
- resume filtering and screening tools for companies
- 求职者自动搜索代理
- automated search agents for job seekers
- 提高查询性能
- improved query performance
从粗略的产品开发路线图开始，我们使用两个问题来启动发布计划：
Starting with a rough product development roadmap, there are two questions we use to initiate release planning:
- 我们什么时候想要发布？
- When do we want the release?
- 每个故事的优先级是什么？
- What is the priority of each story?
一旦我们得到这些问题的答案，我们就会通过估计团队在每次迭代中能够完成的工作量来计划发布。使用我们在一次迭代中可以完成多少工作的估计，我们可以合理预测需要多少次迭代才能生成满足客户期望的版本。
Once we have the answers to these questions we plan the release by estimating how much work the team will be able to accomplish in each iteration. Using this estimate of how much work we can do in an iteration, we make a reasonable prediction about how many iterations it will take to produce a release that meets the customer’s expectations.
我们什么时候想要发布？
When Do We Want the Release?
理想情况下，开发人员和客户可以讨论日期范围，而不是具体日期：“我们希望在 5 月发布，但只要我们在 7 月的某个时候发布，就可以了。” 一个迭代的、故事驱动的过程使得确定日期很容易，但很难确定给定日期将包含的内容。如果一个团队可以在可接受的日期范围内开始发布计划，他们将在发布时间上有更大的灵活性。例如，从心中的日期范围开始，团队可以做出这样的声明：“经过六到七次迭代后，我们应该拥有最少的功能，也许十到十二次之后，我们才能拥有 1.0 愿望清单上的所有内容。”
Ideally, the developers and the customer can talk about a range of dates, rather than a specific date: “We’d like to release in May, but as long as we release sometime in July, that’s fine.” An iterative, story-driven process makes it easy to fix a date but difficult to fix what will be included by a given date. If a team can start release planning with a range of acceptable dates they will have more flexibility in timing releases. For example, starting with a date range in mind enables a team to make statements like “After six or seven iterations we should have the minimum functionality and maybe ten to twelve before we have everything on the 1.0 wish list.”
在某些情况下，日期确实是固定的。最常见的情况是在为贸易展览、重要客户发布或一些类似的里程碑准备发布时发生。如果是这种情况，发布计划实际上会更容易一些，因为要考虑的变量更少。然而，关于要包含哪些故事的决定通常会更加困难。
In some cases the date truly is fixed. Most commonly this occurs when preparing a release for a trade show, a key customer release, or some similar milestone. If this is the case, release planning is actually a bit easier as there are fewer variables to consider. However, the decisions about which stories to include will usually be more difficult.
你想要什么？
What Would You Like in It?
为了计划发布，客户必须确定故事的优先级。将故事按优先级划分为熟悉的高、中和低类别是有用的，但可能会导致关于什么构成高优先级故事而不是中等优先级故事的乏味争论。幸运的是，我们可以从另一个敏捷过程 DSDM 中借用一种技术。[1]
In order to plan a release, the customer must prioritize the stories. Prioritizing stories into the familiar high, medium and low categories is useful but can lead to tedious arguments over what constitutes a high priority story as opposed to a medium priority story. Fortunately, we can borrow a technique from DSDM, another of the agile processes.[1]
DSDM 包括一种称为 MoSCoW 规则的优先级排序技术。MoSCoW 是
DSDM includes a prioritization technique referred to as the MoSCoW rules. MoSCoW is an acronym for
- 一定有
- Must have
- 应该有
- Should have
- 本来可以
- Could have
- 不会有这个时间
- Won’t have this time
必备功能是系统的基础功能。应有的功能很重要，但有一个短期的解决方法他们。如果项目没有时间限制，应该具备的功能通常会被认为是强制性的。可能有的功能是指在时间用完时可以从发布中删除的功能。优先考虑为不需要的功能是那些需要但承认需要在以后的版本中出现的功能。
The must-have features are those that are fundamental to the system. Should-have features are important but there’s a short-term workaround for them. If the project has no time constraints, the should-have features would normally be considered mandatory. Could-have features are ones that can be left out of the release if time runs out. Features prioritized as won’t-have are ones that are desired but acknowledged as needing to come in a later release.
优先考虑故事
Prioritizing the Stories
我们可以从多个维度对故事进行排序。我们可以使用的技术因素包括：
There are many dimensions along which we can sort stories. Among the technical factors we can use are:
- 故事无法按预期完成的风险（例如，具有所需的性能特征或新颖的算法）
- the risk that the story cannot be completed as desired (for example, with desired performance characteristics or with a novel algorithm)
- 如果推迟，故事对其他故事的影响（我们不想等到最后一次迭代才知道应用程序是三层和多线程的）
- the impact the story will have on other stories if deferred (we don’t want to wait until the last iteration to learn that the application is to be three-tiered and multi-threaded)
此外，客户和用户有自己的一组因素可以用来对故事进行排序，包括以下内容：
Additionally, customers and users have their own set of factors they could use to sort the stories, including the following:
- 故事对广泛的用户或客户群的吸引力
- the desirability of the story to a broad base of users or customers
- 故事对少数重要用户或客户的吸引力
- the desirability of the story to a small number of important users or customers
- 故事相对于其他故事的凝聚力（例如，“缩小”故事本身可能不是高优先级，但可能被视为高优先级，因为它是对“放大”的补充，后者是高优先级）
- the cohesiveness of the story in relation to other stories (for example, a “zoom out” story may not be high priority on its own but may be treated as such because it is complementary to “zoom in,” which is high priority)
总的来说，开发人员和客户都有一个他们想要实现故事的顺序。当对顺序有不同意见时，客户获胜。每次。
Collectively, the developers have a sequence in which they would like to implement the stories, as will the customer. When there is a disagreement to the sequence, the customer wins. Every time.
但是，如果没有来自开发团队的一些信息，客户无法确定优先级。至少，客户需要知道每个故事大约需要多长时间。在对故事进行优先排序之前，已经对它们进行了估算，并将估算值写在故事卡上，如故事卡 9.1所示。
However, customers cannot prioritize without some information from the development team. Minimally, a customer needs to know approximately how long each story will take. Before the stories are prioritized, they have already been estimated and the estimates written on the story cards, as shown in Story Card 9.1.
在这一点上，客户不会对估计进行加总，也不会就发布中适合或不适合的内容做出决定。相反，她使用估算值以及她自己对每个故事价值的评估来对故事进行分类，以便它们最大限度地为组织提供价值。一个特定的故事可能对组织非常有价值，但需要一个月的时间来开发。一个不同的故事可能只有一半的价值，但可以在一天内发展起来。
At this point the customer does not sum the estimates and make decisions about what will or won’t fit in a release. Instead, she uses the estimates, along with her own assessment of the value of each story, to sort the stories so that they maximize the value delivered to the organization. A particular story may be highly valuable to the organization but will take a month to develop. A different story may only be half as valuable but can be developed in a day.
故事卡 9.1。提供指向以前查看过的项目的链接。
Story Card 9.1. Provide links back to previously viewed items.
成本变更优先级
几年前，我的团队正在为一位正在从旧的基于 DOS 的系统转换大型应用程序的客户构建 Windows 用户界面。在 DOS 系统中，Enter 键用于在字段之间移动。客户希望我们在她的新 Windows 系统中做同样的事情。从她的客户角度来看，使用 Enter 或 Tab 将花费相同的开发时间是合乎逻辑的。但是，我们估计使用 Enter 键大约需要一个额外的人一周。听到这个消息后，我们的客户很快就降低了对该故事的重视程度。当她认为只有几个小时时，这对她来说是一个高度优先的事情；一周后，她决定还有很多其他的东西她宁愿拥有。
A few years ago my team was building a Windows user interface for a customer who was transitioning a large application from an old DOS-based system. In the DOS system the Enter key was used to move forward between fields. The customer wanted us to do the same in her new Windows system. From her customer perspective it was logical that it would take the same amount of development time to use either Enter or Tab. However, we estimated that it would take about an extra person week to use the Enter key. After hearing that, our customer quickly lowered her priority on that story. It was a high priority to her when she thought it was a few hours; when it was a week, there were many other things she decided she would rather have.
混合优先级
Mixed Priorities
如果客户无法确定故事的优先级，则可能需要拆分故事。拆分故事允许客户以不同的方式优先考虑单独的故事。在一个项目中，我的故事描述显示在Story Card 9.2中。客户很难确定故事的优先级，因为按作者和标题搜索是必不可少的，而其他搜索字段被认为不错但不是必需的。故事被分成三部分：一个故事用于按作者或标题搜索，另一个故事用于按出版物名称或日期搜索，第三个故事允许组合标准。
If a customer is having trouble prioritizing a story, the story may need to be split. Splitting a story allows the customer to prioritize the separate stories differently. On one project I had the story description shown in Story Card 9.2. The customer struggled to prioritize the story because searching by author and title were essential, while the other search fields were considered nice but were not essential. The story was split into three: one story for searching by author or title, another for searching by publication name or date, and a third allowing for the criteria to be combined.
Story Card 9.2. Search criteria.
冒险故事
Risky Stories
回顾早期的软件开发方法，很明显，关于项目是应该首先处理风险最高的部分还是项目中最有价值的部分一直存在争论。风险驱动开发的主要支持者可能是 Barry Boehm，他的螺旋模型侧重于尽早消除风险（1988 年）。另一端是汤姆·吉尔布 (Tom Gilb)，他主张先做“多汁的部分”(1988)。
Looking back over earlier approaches to software development, it is clear that there has been an ongoing debate about whether a project should first go after the riskiest parts or the most valuable parts of the project. Probably the leading proponent of risk-driven development has been Barry Boehm whose spiral model focuses on the early elimination of risk (1988). On the other end has been Tom Gilb who advocates doing the “juicy bits” first (1988).
敏捷方法坚定地站在先做多汁的部分的阵营中。这允许敏捷项目避免提前太早解决风险，并允许他们推迟构建可能不需要的基础架构代码。偏爱多汁的部分也使项目有可能在只有最高价值的功能可用时提前发布。
Agile approaches are firmly in the camp of doing the juicy bits first. This allows agile projects to avoid solving risks too far in advance and allows them to defer building infrastructural code that may not be needed. Favoring the juicy bits also makes it possible for a project to release early, when only the highest-valued functionality is available.
但是，即使是先追求有趣的部分，我们在确定故事的优先级时仍然需要考虑风险。许多开发人员倾向于先做风险最大的故事。有时这是合适的，但仍必须由客户做出决定。但是，客户在确定故事的优先级时会考虑技术团队的意见。
But, even when going after the juicy bits first, we still need to consider risk when prioritizing stories. Many developers have a tendency to want to do the riskiest stories first. Sometimes this is appropriate but the decision must still be made by the customer. However, the customer considers input from the technical team when prioritizing the stories.
在生物技术领域最近的一个项目中，一些故事要求对一种称为期望最大化的标准统计方法进行新颖的扩展。因为正在进行的工作是真正的新工作，团队无法确定它是否能够完成或需要多长时间。如果不包含这些故事，该产品仍然可以销售，因此客户将它们优先放在堆栈的中间位置。然而，一旦客户意识到与这些故事相关的极高风险，他们中的足够多的人就会被赋予更高的优先级，以确定开发新算法所涉及的内容。
On one recent project in the biotech space some of the stories called for novel extensions to a standard statistical approach called expectation maximization. Because the work being undertaken was truly new, the team could not be sure if it could be accomplished at all or how long it would take. The product would still have been saleable without the inclusion of these stories, so the customer prioritized them to be near the middle of the stack. However, once the customer was made aware of the extremely high risk associated with these stories, enough of them were given higher priorities in order to determine what was involved in developing the novel algorithms.
优先考虑基础设施需求
Prioritizing Infrastructural Needs
风险故事通常与基础设施或非功能性需求（例如性能）相关联。我在一个项目中开发一个网络程序将显示股票价格图表。我们的故事之一显示在故事卡 9.3中。对于已指定的基线 Web 服务器机器，这种性能水平可能是一个重大挑战。满足此性能要求的难度将对我们的架构决策产生深远影响。
Frequently the risky stories are associated with infrastructural or nonfunctional needs such as performance. I was on a project to develop a web program that would display charts of stock prices. One of our stories is shown in Story Card 9.3. For the baseline web server machinery that had been specified, this level of performance could be a significant challenge. The difficulty of meeting this performance requirement would have a profound impact on our architectural decisions.
我们已经承诺将 Java 作为我们的服务器端语言，但我们能否使用 Java 实现每秒 50 张图像？我们是否需要使用原生 C 或 C++ 代码来生成图像？或者我们是否可以使用强大的缓存算法来实现我们的吞吐量目标，该算法将为仅相隔几秒钟的请求提供相同的图表？
We’d already committed to Java as our server-side language but could we achieve 50 images per second with Java? Would we instead need to go with native C or C++ code for the image generation? Or could we achieve our throughput goal with a strong caching algorithm that would serve up the same chart for requests that were only seconds apart?
故事卡 9.3。每秒生成 50 张图像。
Story Card 9.3. Generate 50 images per second.
在这种情况下，客户为我们编写了Story Card 9.3。然而，她的优先级相当低。我们的前几次迭代将针对开发可以向潜在客户展示并用于产生初始销售和对产品的兴趣的功能。我们的客户认为我们以后总是可以添加可扩展性。在某些情况下，重构系统以提高其可扩展性很容易。在其他情况下，这种类型的重构可能非常困难。开发人员可以通过确定可以推迟但如果稍后实施可能会增加开发成本的故事来帮助客户。但是，开发人员不得将此作为引导客户尽早实施他们最喜欢的技术功能的许可。
In this case the customer had written Story Card 9.3 for us. However, she prioritized it fairly low. Our first few iterations would be targeted at developing features that could be shown to prospects and used to generate initial sales and interest in the product. Our customer reasoned that we could always add scalability in later. In some cases it is easy to refactor a system to improve its scalability. In other cases, that type of refactoring can be very difficult. It is up to the developers to help the customer by identifying stories that can be deferred but may become much more costly to develop if implemented later. Developers must not, however, take this as a license to steer the customer toward early implementation of their favorite technical features.
在另一个项目中，客户显然希望应用程序可以部署为一个三层应用程序，其中包含一个数据库服务器、一个客户端计算机和一个在它们之间路由请求和数据的中间层。客户在各种会议上与团队讨论过这个问题，她正在准备的营销文献将系统描述为三层。但是，没有一个故事是写的，因此需要添加中间层。
On another project, the customer clearly wanted the application to be deployable as a three–tiered application with a database server, a client machine, and a middle-tier that would route requests and data between them. The customer had talked with the team about this in various meetings and the marketing literature she was preparing described the system as three-tiered. However, none of the stories was written so that it required the addition of the middle tier.
这给技术团队带来了麻烦。他们不介意从一个简单的两层系统（数据库服务器和客户端机器）开始，但经过几次迭代后，他们越来越担心没有添加中间层。他们知道添加中间层仍然很容易，但每次迭代都会变得有点困难。此外，由于编写用户故事时完全关注最终用户功能，因此不清楚何时会添加此类基础设施需求。
This was becoming troubling to the technical team. They did not mind starting with a simple two-tiered system (database server and client machine) but after a couple of iterations had gone by they became more and more concerned that the middle tier had not been added. They knew that adding the middle tier would still be easy but that it would get a little harder with each iteration. Also, because the user stories were written with their focus entirely on end-user functionality it was not clear when such an infrastructural need would be added.
解决方案是编写一个故事，使三层功能成为优先考虑团队工作的客户的更高优先级。在这种情况下，我们添加了故事：“在安装过程中，用户可以决定在她的 PC 上本地安装所有内容，或者分别安装客户端、中间层和服务器。”
The solution was to write a story that made the three-tier capability a higher priority to the customer who was prioritizing the team’s work. In this case we added the story: “During installation the user can decide to install everything locally on her PC or to install the client, middle-tier and server separately.”
选择迭代长度
Selecting an Iteration Length
开发人员和客户共同选择适合他们的迭代长度。迭代长度通常为一到四个星期。短迭代允许更频繁地更正项目的过程并更清楚地了解其进度；但是，每次迭代都会产生一些开销。在看起来有点太短而不是看起来有点太长的迭代方面犯错误。
Collectively the developers and the customer select an iteration length that will work for them. Iteration lengths are typically from one to four weeks. Short iterations allow for more frequent course corrections of the project and more visibility into its progress; however, there is a slight overhead associated with each iteration. Err on the side of iterations that seem a little too short rather than ones that seem a little too long.
尽可能在项目期间坚持固定的迭代长度。通过一致的迭代，项目会进入一种自然的节奏，这对团队的节奏是有益的。当然，有时您需要更改迭代长度。例如，一个一直使用三周迭代的团队被要求在八周内为一个重要的贸易展准备下一个版本。他们可以从两个正常的三周迭代开始，然后再进行一个缩短的两周迭代，而不是在两次三周迭代后停止，距离演出还有两周。这没有错。您要避免的是随机更改迭代长度。
As much as possible, stick with a constant iteration length for the duration of the project. With consistent iterations, projects fall into a natural rhythm that can be beneficial to the pace of the team. Naturally there will be times when you need to alter the iteration length. For example, a team that has been using three-week iterations is asked to prepare the next version for an important tradeshow in eight weeks. Rather than stopping after two three-week iterations with two weeks left before the show, they can start with two normal three-week iterations and then follow those with an abbreviated two-week iteration. There’s nothing wrong with this. What you want to avoid is random changes to the iteration length.
从故事点到预期持续时间
From Story Points to Expected Duration
假设客户已对所有故事卡进行优先排序。该团队将每张卡片的估计值相加，得出 100 个故事点。使用故事点可以更轻松地估算故事，但现在我们需要一种方法将故事点转换为项目的预测持续时间。
Suppose that the customer has prioritized all of the story cards. The team sums the estimates from each card and comes up with 100 story points. Using story points made it easier for estimating the stories, but now we need a way to convert story points into a predicted duration for the project.
答案当然是使用速度。正如我们在第 8 章“估算用户故事”中了解到的，速度表示在一次迭代中完成的工作量。一旦我们知道团队的速度，我们就可以用它把理想的日子变成日历日。例如，如果我们估计我们的项目有 100 个理想天数，那么在速度为 25 的情况下，我们可以估计需要 100 / 25 = 4 次迭代才能完成项目。
The answer, of course, is to use velocity. As we learned in Chapter 8, “Estimating User Stories,” velocity represents the amount of work that gets done in an iteration. Once we know a team’s velocity, we can use it to turn ideal days into calendar days. For example, if we estimate our project at 100 ideal days, then with a velocity of 25 we can estimate that it will take 100 / 25 = 4 iterations to complete the project.
初速度
The Initial Velocity
可以通过三种方式获取速度的初始值：
There are three ways to get an initial value for velocity:
1.使用历史价值。
1. Use historical values.
2. 运行初始迭代并使用该迭代的速度。
2. Run an initial iteration and use the velocity of that iteration.
3. 猜一猜。
3. Take a guess.
使用历史值是最好的选择，但只有当我们有一个现有团队正在推出与新项目类似的项目并且没有人加入或离开该团队时，它才可行。不幸的是，完全相同的团队很少会同时从事两个相似的项目。
Using historical values is the best option, but it is only viable if we have an existing team that is rolling off a project similar to the new project and if no one is joining or leaving the team. Unfortunately, it is rare that the exact same team gets to work on two consecutive similar projects.
运行初始迭代是获得起始速度的好方法。但是，很多时候这是不可行的。例如，假设你的老板带着一个新的产品创意来找你。她编写了她认为在第一个版本中需要的用户故事。她利用这些故事进行市场调查，并认为该产品第一年将赚取 500,000 美元。如果可以开发出足够便宜的产品，公司就会追求它。如果没有，他们将通过。当你的老板问你开发成本是多少时，你并不总是可以自由地说，“让我运行两周的样本迭代，然后再给你答复。” 在这种情况下，您需要一种方法来猜测速度。
Running an initial iteration is a great way to get a starting velocity. However, there are many times when this is not viable. For example, suppose your boss comes to you with a new product idea. She’s written the user stories she thinks are needed in the first version. She’s used those stories to do market research and thinks the product will earn $500,000 the first year. If the product can be developed cheaply enough, the company will pursue it. If not, they’ll pass. When your boss asks you what it will cost to develop, you are not always given the freedom to say, “Let me run a sample iteration for two weeks and get back to you.” In cases like this you need a way to take a guess at the velocity.
猜测速度
Guessing at Velocity
如果我们需要猜测速度，我们至少应该以一种在向其他人解释时有意义的方式进行。幸运的是，如果您遵循第 8 章“估算用户故事”中的建议并将故事点定义为大约一个理想的工作日，那么就有一种合理的方法可以做到这一点。
If we need to guess at velocity we should at least do so in a way that makes sense when we explain it to others. Fortunately, there’s a reasonable way of doing this if you followed the advice of Chapter 8, “Estimating User Stories,” and defined a story point as approximately one ideal day of work.
如果一个故事点是一个理想的工作日，我们可以通过估计完成一个完整的理想工作日需要多少实际天数来估计初始速度。在迭代过程中，很明显团队会遇到许多干扰，这会阻止团队拥有理想的日子。由于回复电子邮件、电话、全公司会议、部门会议、培训、进行或参加演示、洗老板的车、面试新候选人、生病、休假等，他们实际的日子会与理想的日子不同. 由于所有这些中断，通常以迭代中开发人员天数的三分之一到二分之一之间的预期速度开始。例如，使用两周（十个工作日）迭代的六人团队将有六十个开发人员日迭代。他们可能希望估计每次迭代 20 到 30 个故事点之间的速度，具体取决于他们期望的日子与理想日子的差异程度。
If a story point is one ideal day of work, we can estimate initial velocity by estimating how many actual days it will take us to complete a full ideal day of work. Over the course of an iteration it is clear the team will have many interruptions that will prevent the team from having ideal days. Their actual days will differ from ideal days because of time spent answering email, phone calls, all-company meetings, departmental meetings, training, giving or attending demos, washing the boss’ car, interviewing new candidates, illnesses, vacation, and so on. Because of all of these interruptions it is common to start with an expected velocity that is somewhere between one-third and one-half the number of developer-days in an iteration. For example, a six-person team using two-week (ten working day) iterations would have sixty developer-days each iteration. They may want to estimate velocity between 20 and 30 story points per iteration depending on how different they expect their days to be from ideal days.
当然，随着项目在前几次迭代中取得进展，团队将对项目的持续时间有更好的感觉。他们将在一两次迭代中知道他们的速度估计值有多远，并且能够改进估计值并更有信心地传达计划。
Of course, as the project progresses through the first few iterations the team will gain a much better feeling for the duration of the project. They’ll know within an iteration or two how far off their velocity estimate was and will be able to refine the estimate and communicate the plan with more confidence.
创建发布计划
Creating the Release Plan
因此，如果项目有 100 个故事点，我们估计每次迭代 20 个故事点的速度，那么我们可以预期它需要五次迭代。发布计划的最后一步是将故事分配到每个迭代中。客户和开发人员协作选择价值最高优先级故事的 20 个故事点，并将它们放入第一次迭代中。接下来的二十个故事点进入第二次迭代，依此类推，直到分配完所有故事。
So, if the project has 100 story points and we estimate velocity at 20 story points per iteration, then we can expect it to take five iterations. The final step in release planning is to allocate stories into each of the iterations. Collaboratively the customer and the developers select twenty story points worth of the highest priority stories and place them into the first iteration. The next twenty story points go into the second iteration and so on until all the stories have been allocated.
根据团队是否完全协同（包括高层管理人员等利益相关者）和组织对正式性的需要，有多种方式来传达发布计划。例如，我使用了以下各项：
Depending on whether the team is entirely collocated (including stakeholders such as upper managers) and the organization’s need for formality, there are many ways to communicate a release plan. For example, I’ve used each of the following:
- 对于并置的团队，我使用列将故事卡片固定在墙上以指示迭代。
- With a collocated team, I’ve pinned story cards to the wall using columns to indicate the iterations.
- 对于电子表格中的故事，我根据故事的迭代对故事进行了排序，然后在每次迭代的最后一个故事之后画了一条粗粗线。
- With stories in a spreadsheet, I’ve sorted the stories based on their iterations and then drawn a thick bold line after the last story in each iteration.
- 对于感兴趣的远程利益相关者，我已经影印了记事卡（一页三张，如果缩小尺寸，一页六张）。我指出每次迭代的开始并添加一个漂亮的封面。
- For interested remote stakeholders, I’ve photocopied notecards (three to a page, or six to a page if you reduce the size). I indicate the start of each iteration and add a nice cover page.
- 对于感兴趣的、高规格的、远程的利益相关者，我创建了简单的甘特图。我创建了诸如“Iteration 1”之类的条目，然后将该迭代的故事名称列为从属项。
- For interested, high ceremony, remote stakeholders, I’ve created trivial Gantt charts. I create entries like “Iteration 1” and then list as subordinate to it the story names for that iteration.
一个警告
注意不要对发布计划抱有太大的信心。本章中描述的技术将帮助您估算项目的大致持续时间，并允许您做出类似“产品将在大约 5-7 次迭代后准备好发布”的陈述。然而，它们并没有给你足够的精确度，比如“我们将在 6 月 3 日完成”之类的话。
Be careful not to put too much faith in the release plan. The techniques described in this chapter will help you estimate the approximate duration of a project and allow you to make statements like “The product will be ready for release in approximately 5–7 iterations.” They don’t give you enough precision, however, to say things like “We’ll be done on June 3.”
使用发布计划来设定初始期望，然后在您获得新信息时不断地重新设置这些期望。监控每次迭代的速度，并在您了解到影响估计的新内容时重新估计故事。
Use the release plan to set initial expectations but then constantly reset those expectations as you gain new information. Monitor each iteration’s velocity and re-estimate the stories whenever you learn something new that affects the estimates.
概括
Summary
- 在计划发布之前，有必要大致了解客户希望发布的时间以及故事的相对优先级。
- Before planning a release it is necessary to know approximately when the customer would like the release and the relative priorities of the stories.
- 故事应该按特定顺序（第一、第二、第三等）而不是按组（非常高、高、中等）排列优先级。
- Stories should be prioritized into a specific order (first, second, third and so on) rather than into groups (very high, high, medium and so on).
- 故事由客户确定优先级，但由开发人员提供输入。
- Stories are prioritized by the customer but with input from the developers.
- 使用速度将理想日期中的估计值转换为日历时间。
- Estimates, which are in ideal days, are converted into calendar time using velocity.
- 通常需要估计团队的初始速度。
- It is often necessary to estimate a team’s initial velocity.
开发者责任
Developer Responsibilities
- 您有责任向客户提供信息（有时包括您的基本假设和可能的备选方案），以帮助她确定故事的优先级。
- You are responsible for providing information (sometimes including your underlying assumptions and possible alternatives) to the customer in order to help her prioritize the stories.
- 您有责任抵制将基础设施或体系结构需求优先于应有的优先级的冲动。
- You are responsible for resisting the urge to prioritize infrastructural or architectural needs higher than they should be.
- 您负责创建基于实际估计但包含适当大小的项目缓冲区的发布计划。
- You are responsible for creating a release plan that is built on realistic estimates yet includes an appropriately sized project buffer.
客户责任
Customer Responsibilities
- 您有责任按照您重视的精确顺序对用户故事进行优先级排序。将它们分类为高、中、低优先级的堆栈是不够的。
- You are responsible for prioritizing the user stories into the precise order you value them. It is not sufficient to sort them into stacks of high, medium and low priority.
- 您有责任诚实地说明发布的截止日期。如果您在 7 月 15 日需要它，请不要为了安全起见告诉开发人员您在 6 月 15 日需要它。
- You are responsible for expressing your honest deadlines for the release. If you need it on July 15th, don’t tell the developers you need it on June 15th just to be safe.
- 您有责任了解理想时间和日历时间之间的区别。
- You are responsible for understanding the difference between ideal time and calendar time.
- 您负责拆分包含您希望不同优先级的组件的故事。
- You are responsible for splitting stories that contain components that you want prioritized differently.
- 你有责任理解为什么个人速度为 0.6 的程序员不应该因为她的速度低于 1.0 而受到谴责或批评。
- You are responsible for understanding why a programmer with a personal velocity of 0.6 should not be reprimanded or criticized because her velocity is less than 1.0.
问题
Questions
9.1 估计团队初始速度的三种方法是什么？
9.1 What are three ways of estimating a team’s initial velocity?
9.2 假设一周的迭代和一个由四名开发人员组成的团队，如果他们的速度为 4，团队需要多少次迭代才能完成一个有 27 个故事点的项目？
9.2 Assuming one-week iterations and a team of four developers, how many iterations will it take the team to complete a project with 27 story points if they have a velocity of 4?
第 10 章计划迭代
Chapter 10. Planning an Iteration
发布计划给我们留下了粗粒度的故事分配给构成发布的迭代。这种级别的计划——没有太多细节以至于我们给人以精确和准确的错觉，但足够的计划让我们可以根据它采取行动——是计划发布的理想选择。然而，在每次迭代开始时，将计划过程更进一步是很重要的。
Release planning has left us with a coarse-grained allocation of stories to the iterations that comprise a release. This level of planning—not so much detail that we give the false feeling of precision and accuracy, but enough planning that we can base actions on it—is ideal for planning a release. However, at the start of each iteration it is important to take the planning process one step further.
迭代计划概述
Iteration Planning Overview
为了计划一次迭代，整个团队召开一次迭代计划会议。客户以及团队中的所有开发人员（即程序员、测试人员和其他人员）出席并参与此会议。由于团队将详细查看这些故事，因此他们无疑会对这些故事产生一些疑问。他们需要在场的客户来回答这些问题。
To plan an iteration the whole team holds an iteration planning meeting. The customer as well as all of the developers (that is, programmers, testers and others) on the team attend and participate in this meeting. Because the team will be looking at the stories in detail, they will undoubtedly have some questions about them. They need the customer present to answer these questions.
迭代计划会议的一般活动顺序如下：
The general sequence of activities for an iteration planning meeting is as follows:
1. 讨论一个故事。
1. Discuss a story.
2. 将故事分解为其组成任务。
2. Disaggregate the story into its constituent tasks.
3. 一名开发人员对每项任务负责。
3. One developer accepts responsibility for each task.
4. 在讨论完所有故事并接受所有任务后，开发人员单独估算他们接受的任务以确保他们没有过度承诺。
4. After all stories have been discussed and all tasks have been accepted, developers individually estimate the tasks they’ve accepted to make sure they are not over-committed.
以下各节之一讨论了每项活动。
Each of the activities is discussed in one of the following sections.
讨论故事
Discussing the Stories
作为迭代计划会议的输入，团队拥有一组优先故事。正如程序员可能会改变他们对编写故事的难度的看法一样，客户也可能会改变她对故事优先级的看法。迭代计划会议是客户向团队表达这些优先级变更的最佳时机。
As input to the iteration planning meeting, the team has the set of prioritized stories. Just as programmers may change their opinions about the difficulty of programming a story, the customer may change her mind about the priority of a story. The iteration planning meeting is the perfect time for the customer to express these priority changes to the team.
会议开始时，客户从她优先级最高的故事开始，然后向开发人员朗读。然后开发人员提出问题，直到他们充分理解故事，将其分解为组成任务。没有必要了解故事的每个细节，过分深入每个故事的细节会使会议变得非常冗长和低效，因为会议中的每个人都不需要听到所有故事的所有细节。在计划会议之后，开发人员仍然能够与客户一起制定故事的细节。
To start the meeting, the customer starts with her highest priority story and reads it to the developers. The developers then ask questions until they understand the story sufficiently to disaggregate it into constituent tasks. It is not necessary to understand every detail of the story, and diving too deeply into the details of each story can make the meeting very lengthy and inefficient, since not everyone in the meeting needs to hear all the detail on all stories. The developers will still be able to work out the fine details of the stories with the customer after the planning meeting.
改变优先级
通常最好的情况是客户能够承受在期间更改优先级的愿望一次迭代。如果客户频繁改变主意，团队很容易在迭代过程中被打败。例如，在一个项目中，客户和程序员会面并就数据库搜索功能的工作方式达成一致。在 10 天的迭代中的 5 天（大约三分之二是通过对搜索功能进行编码），客户提出了她认为更好的解决方案，该解决方案与原始的、部分编码的解决方案完全不同。那时，在她看来，客户正在比较两个未编码的解决方案，她自然会偏爱她认为更好的那个。她敦促团队放弃当前的方法并立即开始采用新方法。我们礼貌地请她等到迭代结束，她同意了。在那时候，
It is usually best if the customer can withstand the desire to change priorities during an iteration. It is very easy for a team to get whipsawed during an iteration if the customer changes her mind frequently. On one project, for example, the customer and a programmer met and agreed about how a database search feature would work. Five days into a ten-day iteration (and about two-thirds through coding the search feature), the customer came up with what she thought was a better solution that was completely different from the original, partially coded solution. At that point, in her mind the customer was comparing two uncoded solutions and she naturally favored the one she thought was better. She urged the team to abandon the current approach and immediately start on the new approach. We politely asked her to wait until the end of the iteration and she agreed. At that point, she was comparing a fully working solution that did most of what she wanted in a search feature and another version that was undoubtedly better but that would take 10 days to develop.
尽管她（和团队的其他成员）认为新的搜索功能会更好，但与完全可用的功能相比，在那个时候不值得添加。让开发人员开发全新的功能可以更好地为用户服务。
Even though she (and the rest of the team) thought the new search feature would be better, it was not worth adding at that point when compared to a fully working adequate feature. Users were better served by having developers work on entirely new features.
分解为任务
Disaggregating into Tasks
将故事分解为任务确实没有艺术可言。许多开发人员在其职业生涯的大部分时间里都在这样做。由于故事已经相当小（通常需要项目的原型程序员一到五天的理想时间），所以通常不需要那么多的分解。
There is really no art to disaggregating a story into tasks. Many developers have been doing this for much of their careers. Since stories are already fairly small (typically taking the project’s archetypal programmer one to five days of ideal time) there is usually not that much disaggregation necessary.
事实上，为什么要分解呢？为什么不把故事单独作为一个独立的工作单元呢？
In fact, why disaggregate at all? Why not leave the story alone as a discrete unit of work?
尽管故事小到足以作为工作单元，但通常通过将故事分解成更小的任务来很好地服务于项目。首先，对于许多团队来说，故事不会仅由一个开发人员（或一对开发人员）来实现。故事可能会在开发人员之间拆分，因为开发人员专注于某些技术，或者因为拆分工作是完成故事的最快方式。
Even though stories are small enough to serve as units of work, projects are generally well served by disaggregating them into even smaller tasks. First, for many teams the story will not be implemented by just one developer (or one pair of developers). The story may be split among developers either because the developers specialize in certain technologies or because splitting the work is the fastest way to complete the story.
其次，故事是对用户或客户有价值的功能的描述；它们不是开发人员的待办事项列表。将故事转化为其构成任务的行为通常很有用，因为它有助于指出可能被遗忘的任务。因为分解任务是在团队环境中进行的，所以团队的全部力量都会投入到工作中。虽然一个开发人员可能会忘记更新安装程序作为故事的一部分是必要的，但不太可能每个人都会忘记。
Second, stories are descriptions of user- or customer-valued functionality; they are not to-do lists for developers. The act of converting a story into its constituent tasks is often useful because it helps point out tasks that might have been forgotten. Because the disaggregation into tasks happens in a group setting, the entire strength of the team is brought to the effort. While one developer may forget that it’s necessary to update the install program as part of a story, it is less likely that everyone will forget.
对敏捷过程的批评之一是没有预先设计步骤，而瀑布过程中有。虽然确实没有前期设计阶段，但敏捷流程的特点是频繁的短时间突发设计。将故事分解为任务——这只能在至少考虑到最小设计的情况下才能完成——是这些短暂的即时设计中的一种，它取代了瀑布的前期设计阶段。
One of the criticisms of agile processes is that there is no upfront design step, as there is in a waterfall process. While it’s true there is no upfront design phase, agile processes are characterized by frequent short bursts of design. Disaggregating stories into tasks—which can only be done with at least a minimal design in mind—is one of these short bursts of just–in–time design that replace a waterfall’s upfront design phase.
当不同的团队成员提出构成故事的任务时，团队中的某个人需要将任务写在某物上。我个人的偏好是将它们写在共享团队会议室的白板上。
As various team members call out the tasks that comprise a story, someone on the team needs to write the tasks on something. My personal preference is to write them on a white board in a shared team meeting room.
作为将故事分解为任务的示例，假设我们有故事“用户可以在各个领域搜索酒店”。这个故事可能会变成以下任务：
As an example of disaggregating a story into tasks, suppose we have the story “A user can search for a hotel on various fields.” That story might be turned into the following tasks:
- 代码基本搜索屏幕
- code basic search screen
- 代码高级搜索屏幕
- code advanced search screen
- 代码结果屏幕
- code results screen
- 编写和调整 SQL 以查询数据库以进行基本搜索
- write and tune SQL to query the database for basic searches
- 编写和调整 SQL 以查询数据库以进行高级搜索
- write and tune SQL to query the database for advanced searches
- 在帮助系统和用户指南中记录新功能
- document new functionality in help system and user’s guide
请特别注意更新用户指南和帮助系统的任务。尽管这个故事没有明确说明任何关于文档的内容，但团队从之前的迭代中知道有一个帮助系统和用户指南，并且它们需要在每次迭代结束时准确无误。如果对此有任何疑问，团队可以询问客户。
In particular notice the inclusion of the task for updating the user’s guide and help system. Even though this story did not explicitly say anything about documentation, the team knew from prior iterations that there are a help system and a user’s guide and that they need to be accurate at the end of each iteration. If there was any question about this the team could have asked the customer.
准则
Guidelines
因为故事已经相当小了，所以没有必要围绕任务的期望大小设置非常精确的指导方针。在将故事分解为任务时使用这些准则：
Because stories are already fairly small it is not necessary to set very precise guidelines around the desired size of a task. Use these guidelines when disaggregating stories into tasks:
- 如果故事中的一个任务特别难以估计（例如，支持的数据格式列表需要远程副总裁的批准，而副总裁响应速度很慢），请将该任务与故事的其余部分分开。
- If one task of a story is particularly difficult to estimate (for example, a list of supported data formats requires approval from a remote Vice President who is slow to respond), separate that task from the rest of the story.
- 如果任务可以由不同的开发人员轻松完成，则拆分这些任务。例如，在上述案例中，基本和高级搜索屏幕的编码是分开的。让同一个程序员或两人同时工作可能会产生一些自然的协同作用，但这不是必需的。以这种方式分解任务很有用，因为它可以让多个开发人员处理同一个故事。当时间开始耗尽时，这在迭代快要结束时经常是必要的。类似地，如果团队使用用户界面设计器或组，任务“代码基本搜索屏幕”可以拆分为两个任务：“为基本搜索屏幕设计屏幕布局”和“代码基本搜索屏幕”。
- If tasks could easily be done by separate developers, then split those tasks. For example, in the case above, coding of the basic and advanced search screens was separated. There may be some natural synergy to having the same programmer or pair work on both but it isn’t necessary. Disaggregating tasks in this way is useful because it lets multiple developers work on the same story. This is frequently necessary near the end of an iteration as time starts to run out. Similarly, the task “code basic search screen” could have been split into two tasks: “Design screen layout for basic search screen” and “Code basic search screen” if the team is using a user interface designer or group.
- 如果知道故事的一部分已经完成有好处，那就把那部分分解成一项任务。在上面的示例中，基本和高级搜索屏幕的编码是单独的任务。这将允许编写数据库访问代码的开发人员在搜索屏幕可用时将她的 SQL 连接到搜索屏幕。这意味着延迟完成高级搜索屏幕不会延迟完成基本搜索屏幕的两个任务。
- If there is benefit in knowing that a part of the story is done, break that part out as a task. In the example above, the coding of the basic and advanced search screens were made separate tasks. This will allow the developer who writes the database access code to connect her SQL to the search screens one at a time as they become available. This means that a delay in the completion of the advanced search screen does not delay completion of the two tasks for the basic search screen.
承担责任
Accepting Responsibility
一旦确定了故事的所有任务，团队中的某个人就需要自愿执行每项任务。如果任务写在白板上，开发人员只需在他们接受的任务旁边写下他们的名字。
Once all the tasks for a story have been identified, someone on the team needs to volunteer to perform each task. If the tasks were written on a white board, developers simply write their names next to the tasks they are accepting.
即使团队将进行结对编程，通常最好为每个任务关联一个名称。此人负责完成任务。如果他需要客户提供更多信息，他就会得到。如果他选择结对编程，他会征求一对。不过，最终，他有责任确保在迭代期间完成任务。
Even if the team will be doing pair programming, it is generally best to associate a single name with each task. This person assumes responsibility for completing the task. If he needs additional information from the customer, he gets it. If he chooses to pair program, he solicits a pair. Ultimately, though, it is his responsibility to make sure the task gets completed during the iteration.
实际上，确保任务完成是团队中每个人的责任。团队需要一种“我们都在一起”的心态。而且，如果在迭代接近尾声时，一位开发人员不打算完成她接受的所有任务，那么团队中的其他人应该尽可能地承担这项工作。
Actually, it’s the responsibility of everyone on the team to make sure the task gets completed. The team needs a “we’re all in this together” mentality. And, if near the end of the iteration, one developer is not going to complete all the tasks she accepted, then others on the team are expected to take on that work to the extent possible.
即使一个人签署了一项任务并接受了它的责任，这些责任在整个迭代过程中也必须是流动的。随着团队在迭代中取得进展，更多地了解任务，发现一些工作比计划更容易但有些比计划更难，承诺需要改变。在迭代结束时，没有人会说“我完成了我的工作，但 Tom 还剩下一些任务。”
Even though an individual signs up for a task and accepts responsibility for it, these responsibilities must be fluid throughout the iteration. As the team progresses through the iteration, learning more about the tasks, finding some work easier than planned but some harder than planned, commitments need to change. At the end of an iteration no one can say “I finished my work, but Tom still had a few tasks left.”
估计和确认
Estimate and Confirm
如果项目团队的速度是每次迭代 40 个故事点，那么前面的步骤——讨论一个故事，将其分解为任务，并接受任务的责任——将重复，直到团队讨论了客户最有价值的 40 个故事点。到那时，每个开发人员都有责任估算她已接受负责的工作量。最好的方法仍然是估计理想时间。
If a project team’s velocity is forty story points per iteration, then the previous steps—discussing a story, disaggregating it into tasks, and accepting responsibility for the tasks—are repeated until the team has discussed the customer’s top forty story points worth of stories. At that point each developer is responsible for estimating the amount of work she has accepted responsibility for. The best way to do this is still to estimate in ideal time.
至此，任务应该足够小，以便可以对它们进行一些可靠的估计。但是，如果没有，请不要担心。最好猜测一下任务的持续时间，然后继续。如果按照本章前面的建议，将负责的开发人员的任务和姓名写在白纸上板，每个开发人员现在都可以将他或她的估计添加到板中。结果类似于表 10.1。
By this point the tasks should be small enough that they can be estimated with some reliability. But, if not, don’t worry about it. Take a best guess at the duration of the task and move on. If, as was recommended earlier in this chapter, the tasks and names of the responsible developers were written on a white board, each developer can now add his or her estimates to the board. The result will look something like Table 10.1.
表 10.1。 跟踪任务、开发人员执行每项任务以及在白板上进行估算很容易。
Table 10.1. It’s easy to track tasks, the developer doing each task, and estimates on a white board.
一旦开发人员估算了她的每项任务，她就需要将它们加起来，并对它们是否可以在迭代期间全部完成做出现实的评估。例如，假设一个为期两周的迭代开始，我已经接受了我现在估计将花费 53 小时的实际任务时间的任务。令人怀疑的是，除了我必须做的所有其他事情，我是否能够将那么多时间直接投入到这些任务上。此时我有以下选择：
Once a developer has estimated each of her tasks, she needs to add them up and make a realistic assessment about whether they can all be completed during the iteration. For example, suppose a two-week iteration is beginning and I have accepted tasks that I now estimate will take 53 hours of actual time on task. It’s doubtful that with everything else I have to do that I will be able to put that much time directly onto these tasks. At this point I have the following options:
- 保留所有的任务和希望
- keep all the tasks and hope
- 请求团队中的其他人承担我的一些任务
- request that someone else on the team take some of my tasks
- 与客户讨论放弃故事（或拆分故事并放弃其中的一部分）
- talk with the customer about dropping a story (or splitting a story and dropping part of it)
如果其中一位开发人员完成了她的工作量评估并认为她可以承担我的任务，那么这些任务的责任就可以转移到她身上。然而，如果没有人有任何额外的能力来承担这些任务，那么客户就必须通过从迭代中删除一些工作来提供帮助。每个开发人员都必须愿意投入到她所注册的工作中。而且，由于团队有一种“我们都在一起”的态度，每个人都需要对团队的整体承诺感到满意。
If one of the developers finishes assessing her workload and feels she can take on my tasks, responsibility for them can move to her. If, however, no one has any additonal capacity to take on the tasks, then the customer has to help by removing some work from the iteration. Each developer must feel comfortable committing to the work she’s signed up for. And, since the team has a “we’re all in this together” attitude, everyone needs to be comfortable with the overall commitment of the team.
概括
Summary
- 迭代计划使发布计划更进一步，但仅限于正在启动的迭代。
- Iteration planning takes release planning one step further but only for the iteration being started.
- 为了计划迭代，团队讨论每个故事并将其分解为组成任务。
- To plan the iteration, the team discusses each story and disaggregates it into its constituent tasks.
- 任务没有强制性的大小范围（例如，三到五个小时）。相反，故事被分解为任务以促进估计或鼓励多个开发人员处理故事的不同部分。
- There is no mandatory size range for tasks (for example, three to five hours). Instead, stories are disaggregated into tasks to facilitate estimation or to encourage more than one developer to work on various parts of the story.
- 一名开发人员对每项任务负责。
- One developer accepts responsibility for each task.
- 开发人员通过评估他们接受的每项任务来评估他们是否过度承诺。
- Developers assess whether they have over-committed themselves by estimating each task they have accepted.
开发者责任
Developer Responsibilities
- 您负责参与迭代计划会议。
- You are responsible for participating in the iteration planning meeting.
- 您负责帮助将所有故事分解为任务，而不仅仅是您可能处理的故事。
- You are responsible for helping to disaggregate all stories into tasks, not just the stories you are likely to work on.
- 您有责任为您将从事的任务承担责任。
- You are responsible for accepting responsibility for the tasks you will work on.
- 您有责任确保承担适当的工作量。
- You are responsible for ensuring you take on an appropriate amount of work.
- 在整个迭代过程中，您有责任监控您剩余的工作量以及您的队友剩余的工作量。如果你有可能完成你的工作，你有责任从你的队友那里接手一些工作。
- Throughout an iteration you are responsible for monitoring the amount of work you have left as well as the amount of work your teammates have left. If you’re likely to finish your work, you are responsible for taking on some work from your teammates.
客户责任
Customer Responsibilities
- 您负责确定将包含在迭代中的故事的优先级。
- You are responsible for prioritizing the stories that will be included in the iteration.
- 您有责任指导开发人员实现他们可以交付的最大商业价值。这意味着，如果自首次制定发布计划以来发现了更高价值的故事，则您有责任调整优先级以实现最大的商业价值。
- You are responsible for directing the developers toward the greatest business value they can deliver. This means that if higher-value stories have come to light since the release plan was first established, you are responsible for adjusting priorities to deliver maximum business value.
- 您负责参与迭代计划会议。
- You are responsible for participating in the iteration planning meeting.
问题
Questions
10.1将这个故事分解成它的组成任务：用户可以查看有关酒店的详细信息。
10.1 Disaggregate this story into its constituent tasks: A user can view detailed information about a hotel.
第 11 章测量和监控速度
Chapter 11. Measuring and Monitoring Velocity
正如您在第 9 章“规划发布”中所回忆的那样，发布计划是通过将项目分解为一系列迭代来创建的，其中每个迭代都包含一定数量的故事点。迭代中完成的故事点数称为项目速度。在计划项目时，我们要么使用已知的速度（如果我们有一个，可能来自另一个类似的项目），要么我们自己编造一个。速度可以成为一种有用的管理工具，因此在每次迭代结束时以及迭代期间查看团队的速度非常重要。
As you recall from Chapter 9, “Planning a Release,” the release plan was created by breaking the project into a series of iterations, where each iteration included a certain number of story points. The number of story points completed in an iteration is known as the project’s velocity. When planning the project, we either used a known velocity (if we had one, perhaps from another similar project) or we made one up. Velocity can be a useful management tool, so it is important to look at the team’s velocity at the end of each iteration as well as during the iterations.
测量速度
Measuring Velocity
因为速度可以是一个如此重要的衡量标准，所以考虑我们将如何衡量它是很重要的。大多数故事都很容易计算：团队在迭代期间完成了它们，因此它们被计算为完整的价值。例如，假设一个团队完成了表 11.1中所示的故事在一次迭代中。从该表中可以看出，团队的速度为 23，这是迭代中完成的故事的故事点数总和。如果发布计划假定的速度明显不同于 23，则可能需要重新考虑项目计划。但是，请注意不要过早调整发布计划。初始速度不仅容易出错，而且在早期迭代期间也可能非常不稳定。您可能希望等待两到三次迭代，直到您对速度有一个更长期的看法。
Because velocity can be such an important measure, it is important to think about how we’ll measure it. Most stories are easy to count: The team completed them during the iteration so they are counted at full value. Assume, for example, that a team completed the stories shown in Table 11.1 during an iteration. As can be seen in this table, the team’s velocity is 23, which is the sum of the story points for the stories completed in the iteration. If the release plan assumed a velocity that is significantly different from 23, it may be necessary to reconsider the project plan. However, be careful about adjusting a release plan too early. Not only is an initial velocity prone to error, it can also be very volatile during early iterations. You may want to wait two or three iterations until you have a longer-term view of velocity.
Table 11.1. Stories completed during an iteration.
但是，团队只完成了部分的故事呢？它们应该包括在速度计算中吗？
But, what about stories the team only partially completed? Should they be included in velocity calculations?
不，在计算速度时你不应该包括部分完成的故事。原因有很多。首先，自然很难确定故事完成的百分比。其次，我们不想通过使用 43.8 之类的小数值来报告速度的错误精度。第三，不完整的故事通常对用户或客户没有任何价值。因此，即使它们可能已经部分编码，但如果要将软件交付给任何用户，这些故事通常会被排除在正式的迭代结束构建之外。第四，如果故事太大以至于包含部分故事通常会影响速度，比如从 41 到 50，那么故事就太大了。最后，我们迫切希望避免出现许多故事已完成 90%，但很少有人完成 100% 的情况。
No, you should not include partially completed stories when calculating velocity. There are a number of reasons why. First, there’s the natural difficulty of figuring out what percentage of a story is complete. Second, we don’t want to imply a false precision to velocity by reporting it with fractional values like 43.8. Third, incomplete stories do not typically represent anything of value to users or customers. So, even though they may have been partially coded, such stories are often left out of formal end-of-iteration builds if the software is to be delivered to any users. Fourth, if stories are so big that including a partial story routinely affects velocity, say from 41 to 50, then the stories are too large. Finally, we desperately want to avoid a situation where many stories are 90% done, yet few are 100% done. A great deal of complexity can lurk in that last 10%, so it is important to finish each story completely before counting it.
如果您发现自己很想包含部分完整的故事，请评估您的平均故事的大小并考虑争取更小的故事。在确定速度的迭代结束时，放弃一半的单点故事比忽略十二点故事容易得多。此外，如果您经常发现迭代以许多部分完成的故事结束（即使它们都是半点故事），这可能是团队缺乏团队合作的症状。通过全对一的方法，团队将了解到他们最好联合起来完成一些故事，让其他人未开始，而不是部分完成所有故事。
If you find yourself tempted to include partially complete stories, evaluate the size of your average story and consider striving for smaller stories. At the end of an iteration when determining velocity, it is far easier to forego half of a one-point story than it is to ignore a twelve-point story. Additionally, if you frequently find iterations finishing with many partially complete stories (even if they are all half-point stories), this may be a symptom of a lack of teamwork on the team. With an all–for–one approach the team will learn they are better off joining together to complete some stories, leaving others unstarted, than they are partially completing all of them.
Velocity 不使用实际时间
请注意，速度计算是使用迭代开始前分配的故事点值进行的。迭代完成后，不要更改团队在迭代中为任何故事获得的分数。例如，假设一个故事估计有四个故事点，但要大得多。事后，该团队承认他们应该将其估计为 7 分。这个故事对速度计算有四点贡献，而不是七点。
Notice that velocity calculations are made using the story point values assigned before the start of the iteration. Once the iteration is complete, do not change the points the team earns for any story in the iteration. For example, suppose a story was estimated to be four story points but was much larger. After the fact, the team acknowledges they should have estimated it at seven points. This story contrbutes four points to the velocity calculation, not seven.
通常，鼓励团队将下一次迭代的速度规划为不超过前一次迭代的速度。然而，如果团队真的确信一个故事被估计得太低并且他们可以在即将到来的迭代中做更多的事情，那么他们应该被允许计划一个稍微更高的速度。
In general, teams are encouraged to plan the velocity of the next iteration to be no more than the velocity of the prior iteration. However, if the team is truly convinced that a story was estimated too low and they can do more in the upcoming iteration, then they should be allowed to plan on a slightly higher velocity.
虽然团队无法追溯更改已完成故事的要点，但他们应该始终利用此类信息来调整任何未来故事的估计。
While a team cannot retroactively change the points of a completed story, they should always make use of this type of information in adjusting the estimates of any future stories.
计划和实际速度
Planned and Actual Velocity
监控实际速度是否偏离计划速度（更重要的是，它是否需要采取行动）的一个好方法是绘制每次迭代的计划速度和实际速度。这可以在图 11.1中看到，它显示了计划的速度开始很低，但随后增加并在第三次迭代时稳定下来。
A good way to monitor whether actual velocity is deviating from planned velocity—and, more importantly, whether it’s something you need to act on—is to graph planned and actual velocity for each iteration. This can be seen in Figure 11.1, which shows planned velocity starting low but then increasing and stabilizing by the third iteration.
图 11.1。 前三个迭代后的计划速度和实际速度。
Figure 11.1. Planned and actual velocity after the first three iterations.
通过第三次迭代绘制的实际速度超过了第一次迭代的计划速度。但是，第二次和第三次迭代期间的实际改进没有计划的那么大，因此实际速度略低于计划速度。
Actual velocity, graphed through the third iteration, exceeded planned velocity for the first iteration. However, the actual improvements during the second and third iterations were not as great as planned and so actual velocity is slightly less than planned velocity.
如果图 11.1中的团队在第一次迭代结束时告诉客户他们超过了计划的速度并且可以提前交付日期，那么他们就错了。在显示的三个迭代之后呢？团队能否判断他们是否应该调整客户对发布计划的期望？要回答这个问题，团队需要图 11.1的速度图和图 11.2的累积故事点图。
The team of Figure 11.1 would have been wrong if, at the conclusion of the first iteration, they told the customer they were exceeding planned velocity and could move up the delivery date. What about after the three iterations shown? Can the team tell if they should adjust the customer’s expectations about the release plan? To answer that question the team needs both the velocity graph of Figure 11.1 as well as the cumulative story point graph of Figure 11.2.
图 11.2。 绘制累积的计划和实际故事点。
Figure 11.2. Plotting cumulative planned and actual story points.
累积故事点图表显示了在每次迭代结束时完成的故事点总数。因此，我们可以在图 11.2中看到，到第二次迭代结束时，团队完成的故事点比计划的要多，尽管第二次迭代的进度比计划慢得多。然而，到第三次迭代结束时，团队在第一次迭代中开局良好的优势已经被第二次和第三次迭代中较慢的进展所侵蚀。
The cumulative story point chart shows the total number of story points completed through the end of each iteration. So, we can see in Figure 11.2 that through the end of the second iteration the team had completed more story points than planned, even though progress in the second iteration was much slower than planned. However, by the end of the third iteration, the advantage of the team’s good start in the first iteration has been eroded by slower progress during the second and third iterations.
到第三次迭代结束时，团队似乎无法完成计划的那么多功能。如果客户在与团队的日常互动中没有意识到这一点，则应向她说明情况。
By the end of the third iteration it appears probable that the team will not complete as much functionality as planned. If the customer is not aware of this from daily interaction with the team, the situation should be made clear to her.
迭代燃尽图
Iteration Burndown Charts
另一种查看进度的有用方法是使用迭代燃尽图。迭代燃尽图显示了在每次迭代结束时剩余的工作量，以故事点表示。图 11.3显示了一个例子。
Another useful way of looking at progress is through the use of an iteration burndown chart. An iteration burndown chart shows the amount of work, expressed in story points, remaining at the end of each iteration. An example is shown in Figure 11.3.
图 11.3。 迭代燃尽图。
Figure 11.3. An iteration burndown chart.
燃尽图的一个有趣特征是它既反映了以已完成故事点的形式取得的进展，也反映了为发布的剩余部分计划的故事点数量的变化。例如，假设团队在一次迭代中完成了 20 个故事点，但客户向项目添加了 15 个故事点的新工作。二十个故事点反映了只有五个的净收益；如果开发人员的工作处于最佳状态，那么如果客户希望项目能够快速完成，那么她可能不得不放慢新工作的引入。
An interesting feature of a burndown chart is that it reflects both progress made in the form of story points completed, as well as changes to the number of story points planned for the remainder of the release. For example, suppose a team completes twenty story points during an iteration, but the customer adds fifteen story points worth of new work to the project. The twenty story points reflects a net gain of only five; if the developers are working optimally then the customer may have to slow the introduction of new work if she expects the project to be finished quickly.
图 11.3显示了一个团队在第一次迭代中实际上取得了负面的总体进展。他们以 115 个要完成的故事点开始第一次迭代，并以 120 个故事点结束迭代。经理和客户需要小心，不要阅读如图 11.3 所示的燃尽图并对团队大吼大叫。我们无法从燃尽图中看出团队的移动速度有多快。图 11.3中的团队可能已经完成了 90 个故事点，但客户可能已经添加了 95 个。要了解团队完成了多少故事点，请查看速度图表（如图 11.1所示）或累积故事点图表（如图 11.2所示）。
Figure 11.3 shows a team that actually had negative overall progress during the first iteration. They started the first iteration with 115 story points to complete and ended the iteration with 120. Managers and customers need to be careful that they don’t read a burndown chart like Figure 11.3 and go yell at the team. What we can’t tell from a burndown chart is how fast the team is moving. The team on Figure 11.3 may have completed 90 story points, but the customer may have added 95. To know how many story points the team is completing, look at a velocity chart (like the one shown in Figure 11.1) or a cumulative story point chart (like the one shown in Figure 11.2).
燃尽图很有用——尽管它们不能显示开发团队的速度——因为它们可以更好地呈现项目进度的整体视图。敏捷软件开发的一个优点是项目可以在没有冗长的项目需求的前期完整规范的情况下开始。敏捷团队承认客户不可能提前知道所有事情。因此，敏捷团队反而要求客户尽可能多地告诉他们，并允许客户随着项目的进展而改变或完善他们的意见，并且每个人都对正在构建的软件了解更多。这意味着故事会来来去去，故事的大小会改变，故事的重要性也会改变。例如，考虑表 11.2中所示的项目。
Burndown charts are useful—even though they don’t show the speed of the development team—because they present a better overall view of the project’s progress. A strength of agile software development is that a project can begin without a lengthy upfront complete specification of the project’s requirements. Agile teams acknowledge that it is impossible for customers to know everything in advance. So, agile teams instead ask customers to tell them as much as they can and allow customers to change or refine their opinions as the project progresses, and everyone learns more about the software being built. This means that stories will come and go, that stories will change size, and that stories will change in importance. As an example of this, consider the project shown in Table 11.2.
表 11.2。 四次迭代期间的进展和变化。
Table 11.2. Progress and changes during four iterations.
这个项目的团队认为他们每次迭代可以做大约 45 个故事点。他们从 130 个故事点和运行三个迭代的计划开始。他们在第一次迭代中正好完成了 45 个故事点。但是，在完成这些故事时，他们发现剩下的一些故事比最初想象的要大，因此他们将未开始故事的估计值提高了 10 个故事点。此外，客户写了 6 个新故事，每个故事估计有 3 个故事点。这意味着虽然团队完成了 45 个故事点，但他们的净进度为 45-10-18，即 17 个故事点。这意味着在第一次迭代结束时，他们还剩下 113 个故事点。此时团队可以判断他们不会按计划在三个迭代中完成。即使没有新的故事出现，他们还有超过 90 个故事点，这是他们可以合理预期在剩余的两次迭代中完成的数量。客户和团队会面并考虑在 3 次迭代后停止——从软件中保留一些功能——但他们同意让项目运行 4 次迭代。
The team on this project thought they could do around 45 story points each iteration. They started with 130 story points and a plan to run for three iterations. They completed exactly 45 story points in the first iteration. But, in completing those stories, they decided that a few of the remaining stories were bigger than initially thought and they increased the estimates on the unstarted stories by ten story points. Additionally, the customer wrote six new stories, each of which was estimated to be three story points. This means that while the team completed 45 story points, their net progress is 45–10–18, or 17 story points. This means that at the end of the first iteration they have 113 story points remaining. At this point the team could tell they would not finish in three iterations as planned. Even if no new stories came in, they had more than the 90 story points remaining, the amount they could reasonably expect to finish in the remaining two iterations. The customer and team met and considered stopping after three iterations—leaving some functionality out of the software—but, instead they agreed to let the project run for four iterations.
第二次迭代遵循与第一次类似的趋势，团队完成了 47 个故事点，但将未开始故事的估计增加了 4 个点。客户放慢了变化的步伐，但仍添加了价值 8 的新故事故事点。第二次迭代期间的净进度为 47–4–8=35 个故事点。
The second iteration followed a similar trend as the first, with the team completing 47 story points but increasing estimates of unstarted stories by 4 points. The customer slowed the pace of change but still added new stories worth 8 story points. Net progress during the second iteration was 47–4–8=35 story points.
该团队开始了第三次迭代，还剩下 78 个故事点。事情进展顺利，团队完成了价值 48 个故事点的故事。他们还将未开始故事的估计减少了三个故事点。（请记住，在前两次迭代中，对未开始工作的估计有所增加。）客户添加了一两个故事，总共价值四个故事点。第三次迭代的净进度为 48+3-4=47。这只为第四次迭代留下了 31 个故事点，团队在没有进行任何进一步更改的情况下完成了这些故事点。
The team started the third iteration with 78 story points left. Things went well and the team completed stories worth 48 story points. They also reduced estimates of unstarted stories by three story points. (Remember that in the previous two iterations, estimates of unstarted work had gone up.) The customer added a story or two worth a total of four story points. Net progress during the third iteration was 48+3–4=47. This left only 31 story points for the fourth iteration, which the team completed without any further changes.
该项目的燃尽图如图 11.4所示。从这张图中可以看出，从第一次迭代后燃尽线的斜率可以明显看出，该项目在第三次迭代后仍未完成。
A burndown chart for this project is shown in Figure 11.4. As you can see from this chart, it was obvious from the slope of the burndown line after the first iteration that the project would not be finished after three iterations.
图 11.4。 表 11.2中项目的燃尽图。
Figure 11.4. Burndown chart for the project in Table 11.2.
迭代期间的燃尽图
Burndown Charts During an Iteration
除了在迭代结束时跟踪进度之外，燃尽图在迭代期间也是一个很好的管理工具。在迭代过程中，每天的燃尽图显示了估计的剩余小时数迭代。例如，参见图 11.5，它显示了对迭代中剩余小时数的每日跟踪。
Beyond their usefulness for tracking progress at the end of iterations, burndown charts are also a great management tool during the iteration. During an iteration, a daily burndown chart shows the estimated number of hours left in the iteration. For example, see Figure 11.5, which shows a daily tracking of the hours remaining in an iteration.
图 11.5。 每日燃尽图。
Figure 11.5. A daily burndown chart.
我更喜欢通过让每个团队成员在一个公共白板上调整他的剩余时间来收集有关剩余工作量的信息。迭代计划完成后，笔记会留在使用过的白板上。届时，看板将包含一个故事列表，每个故事分解为一个或多个任务。每个任务旁边是程序员注册任务的地方。大约每天一次，我将白板上的数字相加，然后将它们添加到迭代的燃尽图中。在迭代开始附近，这样的白板的一部分看起来类似于图 11.6。
I prefer to collect information on the remaining level of effort by having each team member adjust his hours remaining on a common whiteboard. When iteration planning is done, the notes are left on the whiteboard that was used. At that point the board will contain a list of stories with each story disaggregated into one or more tasks. Next to each task is a place for the programmer to sign up for the tasks. About once a day I add up the numbers on the whiteboard and add them to a burndown chart for the iteration. Near the start of an iteration, a portion of such a whiteboard will look similar to Figure 11.6.
图 11.6。 估算值被写在白板上，并经常被修改。
Figure 11.6. Estimates are written, and frequently revised, on a whiteboard.
图 11.6显示任务“创建 HTML 页面”已经完成，因为它对剩余工作的估计从两个小时变为零。但是，玛丽提高了她对“创建更好的样本数据”任务的估计。玛丽是否还没有开始但改变了主意，或者她是否已经花了两个（或四个或六个）小时并认为还有四个小时都没有关系。重要的是董事会上的估计反映了她目前对剩余工作量的想法。
Figure 11.6 shows that the task “Create HTML page” has been completed as its estimate of remaining work has gone from two hours to none. However, Mary has increased her estimate for the “Create better sample data” task. It doesn’t matter whether Mary hasn’t started but changed her mind, or whether she’s already spent two (or four or six) hours on it and thinks there are four to go. All that matters is that the estimate on the board reflects her current thinking about how much work is left.
团队中的每个人都知道保持数字相对最新。如果在任务完成时或一天结束时更新看板，通常效果最好。这样，一切总是相对最新的。需要鼓励团队中的每个人对剩余工作的估计尽可能准确。程序员需要对增加剩余时间的估计和减少剩余时间的估计一样感到自在。
Everyone on the team knows to keep the numbers relatively current. It usually works best if the board is updated whenever a task is finished or at the end of the day. This way everything is always relatively current. Everyone on the team needs to be encouraged to have the estimates of remaining work be as accurate as possible. Programmers need to feel equally comfortable increasing an estimate of time remaining as they do decreasing it.
剩余小时数，而非已用小时数
请注意，每日燃尽图反映的是剩余工作量，而不是故事或任务上花费的工作量。跟踪花费的小时数可能有几个很好的理由（例如比较实际工作量和计划工作量以提高估算技能，或监控每周花费的生产小时数）。然而，这些都被不记录花费的时间的原因所抵消（例如，大多数开发人员都会感受到被微观管理的感觉，以及数字中的努力或不精确）。
Notice that daily burndown charts reflect the amount of work remaining, not the amount of work expended on a story or task. There may be a few good reasons for tracking hours expended (such as to compare actual to planned effort to improve estimating skills, or to monitor the number of productive hours spent each week). However, these are outweighed by the reasons not to capture hours expended (such as the feeling of being micromanaged most developers will feel and the effort or imprecision in the numbers).
此外，真正重要的是还剩下多少努力，而不是到目前为止付出了多少努力。
Besides, what really matters is how much effort is left, not how much effort has been applied so far.
当然，也可以添加新任务。然而，只有当有人意识到某个任务被遗忘并且这个被遗忘的任务对于完成当前迭代中已经包含的故事是必要的时，才应该添加一个新任务。不应该仅仅因为有人想要在迭代中包含新的东西就添加新任务；这种类型的变化需要在下一次规划会议上优先考虑到迭代中。
Naturally, new tasks can be added, too. However, a new task should be added only when someone realizes that a task was forgotten and the forgotten task is necessary for the completion of a story already included in the current iteration. New tasks should not be added just because someone wants something new included in the iteration; that type of change needs to be prioritized into an iteration at the next planning session.
使用大的、可见的图表
本章中显示的所有图表在放大和可见时最有用。如果您的组织有绘图仪，请在绘图仪上打印图表并将它们挂在团队公共区域或常用走廊的墙上。如果你没有绘图仪，可以考虑在墙上挂几块大白板，然后用它们来绘制图表。
All of the charts shown in this chapter are most useful when made big and visible. If your organization has a plotter then print the charts on the plotter and hang them on a wall in the team’s common area or in a commonly used hallway. If you don’t have a plotter, think about hanging a few large whiteboards on a wall and usng those to draw the charts.
我们在一处公共区域悬挂了三块四英尺乘六英尺的大白板。我在一家文具店买了一些黑色的小胶带，用它在白板上画轴。这给了我们永久的直轴，当我们改变图表时这些轴不会被删除。每周我们都会为三个图表中的每一个添加一个点。周期性地，我们会用完空间，所以我们会擦除图表并重新开始。
At one location we hung three large, four-foot by six-foot whiteboards in a common area. I got some small black tape at a stationery store and used it to draw axes on the whiteboards. This gave us permanently straight axes that weren’t erased when we changed the chart. Each week we’d add a point to each of the three charts. Periodically, we’d run out of space so we’d erase the chart and start over.
概括
Summary
- 在确定速度时，只计算完成的故事，即通过验收测试的故事。不要计算团队在迭代期间部分完成的故事。
- When determining velocity count only finished stories, that is, stories that pass their acceptance tests. Do not count stories the team partially completed during the iteration.
- 监控实际速度和计划速度之间差异的一个好方法是绘制计划的故事点数和每次迭代实际完成的故事点数。
- A good way to monitor differences between actual and planned velocity is to graph both the number of story points planned and those actually completed for each iteration.
- 不要试图仅在一两次迭代后就预测速度趋势。
- Don’t try to predict trends in velocity after only one or two iterations.
- 完成一项任务或一个故事所花费的实际小时数与速度无关。
- The number of actual hours spent completing a task or a story have no bearing on velocity.
- 在每个人都能看到的公共区域张贴可见的大图表。
- Post big, visible charts in common areas where everyone can see them.
- 累积故事点图表（如图 11.2所示）很有用，因为它显示了在每次迭代结束时完成的故事点总数。
- A cumulative story point chart (as shown in Figure 11.2) is useful because it shows the the total number of story points completed through the end of each iteration.
- 迭代燃尽图（如图 11.3所示）以已完成的故事点的形式显示进度，以及为发布的剩余部分计划的故事点数量的变化。
- An iteration burndown chart (as shown in Figure 11.3) shows both progress in the form of story points completed as well as changes to the number of story points planned for the remainder of the release.
- 每日燃尽图显示迭代中每天剩余的小时数，在迭代过程中非常有用。
- A daily burndown chart, showing the hours left on each day of an iteration, is very useful during an iteration.
- 绘制图表并观察每个故事点的团队缺陷有助于表明速度的提高是否是以缺陷为代价的。
- Charting and watching a team’s defects per story point helps indicate if increases in velocity are coming at the expense of defects.
开发者责任
Developer Responsibilities
- 在可能的范围内，您有责任在继续下一个故事之前完成一个故事。拥有少量已完成的故事比拥有稍多一些但全部未完成的故事更可取。
- To the extent possible, you are responsible for completing one story before moving onto the next story. It is preferable to have a small number of completed stories than to have a slightly larger number of stories all incomplete.
- 您有责任了解您所做的任何决定对项目速度的影响。
- You are responsible for understanding the impact of any decision you make on the velocity of the project.
- 您有责任了解如何阅读和解释本章中显示的每个图表。
- You are responsible for understanding how to read and interpret each of the charts shown in this chapter.
- 如果您是经理或者可能在 XP 项目中担任跟踪员角色，您有责任了解如何以及何时创建本章所示的图表。
- If you are a manager or perhaps in the Tracker role on an XP project, you are responsible for knowing how and when to create the charts shown in this chapter.
客户责任
Customer Responsibilities
- 您有责任了解如何阅读和解释本章中显示的每个图表。
- You are responsible for understanding how to read and interpret each of the charts shown in this chapter.
- 您有责任了解团队的速度。
- You are responsible for knowing the velocity of the team.
- 您有责任了解实际速度与计划速度的比较情况，以及是否需要对计划进行修正。
- You are responsible for knowing how actual velocity compares to the planned velocity and whether plan corrections are needed.
- 您负责在发布中添加故事或从中删除故事，以确保在给定约束的情况下尽可能满足项目目标。
- You are responsible for adding or removing stories from the release to ensure that the objectives of the project are met to the extent possible given its constraints.
问题
Questions
11.1估计在一个故事点的故事实际上需要两天时间才能完成。在迭代结束时计算时，它对速度有多大贡献？
11.1 A story estimated at one story point actually took two days to complete. How much does it contribute to velocity when calculated at the end of the iteration?
11.2从每日燃尽图中可以学到哪些在迭代燃尽图中看不到的信息？
11.2 What can you learn from a daily burndown chart that you can’t see on an iteration burndown chart?
11.3你应该从图 11.7中得出什么结论？该项目看起来会提前、延迟还是按计划完成？
11.3 What conclusions should you draw from Figure 11.7? Does the project look like it will finish ahead, behind or on schedule?
图 11.7。 这个项目会提前、推迟或按计划完成吗？
Figure 11.7. Will this project finish ahead, behind or on schedule?
11.4 What is the velocity of the team that finished the iteration shown in Table 11.3?
表 11.3。 迭代期间完成的故事。
Table 11.3. Stories completed during an iteration.
11.5什么情况会导致迭代燃尽图反映上升趋势？
11.5 What circumstances would cause an iteration burndown chart to reflect an upward trend?
11.6 Complete Table 11.4 by writing the missing values into the table.
第三部分：经常讨论的话题
Part III: Frequently Discussed Topics
我们已经了解了什么是故事，我们如何使用它们，以及我们如何估计和计划使用它们。在第 III 部分中，我们首先将注意力转向故事与其他需求方法（如需求规范文档、场景和用例）的不同之处。接下来我们看看用户故事相对于这些其他方法的优势。
We’ve looked at what stories are, how we can use them, and how we can estimate and plan using them. In Part III we start by turning our attention to how stories differ from other requirements approaches such as requirements specification documents, scenarios, and use cases. Next we look at the advantages user stories have over these other approaches.
然而，与任何方法一样，事情有时会出错，我们的注意力会转向一系列气味或可能出现问题的迹象。用户故事起源于极限编程，并且与极限编程关系最密切。在第 III 部分中，我们将看到如何将用户故事添加到另一个敏捷流程 Scrum 中。第 III 部分最后讨论了一些其他较小但经常讨论的主题，例如故事应该写在纸上还是电子存储，故事是否应该针对错误编写，等等。
As with any approach, however, things can sometimes go wrong and our attention turns next to a list of smells, or indicators that something may be amiss. User stories originated in, and are most closely associated with, Extreme Programming. In Part III we will see how user stories can be added to Scrum, another of the agile processes. Part III concludes with a discussion of some additional smaller but frequently discussed topics such as whether stories should be written on paper or stored electronically, whether stories should be written for bugs, and so on.
第 12 章什么不是故事
Chapter 12. What Stories Are Not
为了帮助我们更好地理解什么是用户故事，重要的是要了解它们不是什么。本章解释了用户故事与其他三种常见的需求方法有何不同：用例、IEEE 830 软件需求规范和交互设计场景。
To help us better understand what user stories are, it’s important to look at what they are not. This chapter explains how user stories differ from three other common approaches to requirements: use cases, IEEE 830 software requirements specifications, and interaction design scenarios.
用户故事不是 IEEE 830
User Stories Aren’t IEEE 830
电气和电子工程师协会 (IEEE) 的计算机协会发布了一套关于如何编写软件需求规范的指南 (IEEE 1998)。该文档称为 IEEE 标准 830，最后一次修订是在 1998 年。IEEE 建议涵盖了诸如如何组织需求规范文档、原型制作的作用以及良好需求的特征等主题。IEEE 830 风格的软件需求规范最显着的特征是使用短语“系统应...”，这是 IEEE 推荐的编写功能需求的方式。IEEE 830 规范的典型片段类似于以下内容：
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications (IEEE 1998). This document, known as IEEE Standard 830, was last revised in 1998. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830-style software requirements specification is the use of the phrase “The system shall...” which is the IEEE’s recommended way to write functional requirements. A typical fragment of an IEEE 830 specification looks similar to the following:
4.6) 系统应允许公司使用信用卡支付招聘信息。
4.6) The system shall allow a company to pay for a job posting with a credit card.
4.6.1) 系统应接受维萨卡、万事达卡和美国运通卡。
4.6.1) The system shall accept Visa, MasterCard and American Express cards.
4.6.2) 系统会在招聘信息发布到网站上之前从信用卡中扣款。
4.6.2) The system shall charge the credit card before the job posting is placed on the site.
4.6.3) 系统应给予用户唯一的确认编号。
4.6.3) The system shall give the user a unique confirmation number.
将系统的需求记录到这个级别是乏味的、容易出错的，而且非常耗时。此外，坦率地说，以这种方式编写的需求文档读起来很无聊。只是因为有些事情很无聊阅读并不足以成为放弃它作为一种技术的理由。然而，如果您要处理像这样的 300 页需求（而且那只是一个中型系统），您必须假设它不会被需要阅读它的每个人都彻底阅读。读者会因为无聊而略读或跳过部分内容。此外，在这个级别编写的文档通常会使读者无法掌握全局。
Documenting a system’s requirements to this level is tedious, error-prone, and very time-consuming. Additionally, a requirements document written in this way is, quite frankly, boring to read. Just because something is boring to read is not sufficient reason to abandon it as a technique. However, if you’re dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it is not going to be thoroughly read by everyone who needs to read it. Readers will either skim or skip sections out of boredom. Additionally, a document written at this level will frequently make it impossible for a reader to grasp the big picture.
警告标志
项目因需求规范而误入歧途的一个警告标志是软件开发组与另一组（如市场营销或产品管理）之间的规范文档交换。通常发生的是产品管理（或类似）小组编写提供给开发人员的需求规范。然后开发人员重写此文档，以便它传达他们对产品管理最初编写的需求的解释。开发人员总是小心翼翼地给他们的文档起一个完全不同的名称（也许类似于功能规范），以隐藏它与初始文档是同一个文档，只是从不同组的角度编写的。
One warning sign of a project going astray with a requirements specification is a ping-ponging of the specification document between the software development group and another group like Marketing or Product Management. What typically happens is the Product Management (or similar) group writes a requirements specification that is given to the developers. The developers then rewrite this document so that it conveys their interpretation of the requirements as first written by Product Management. The developers are always careful to give their document a completely different name (something like Functional Specification perhaps) to hide that it is the same document as the initial document, just written from the perspective of a different group.
两个团队都知道，任何重要项目的需求规范都太难阅读和完全理解，并且不可能以所需的精确度编写。因此，无论哪个小组编写最终要求，都可以声称对文档的意图拥有所有权。当项目完成并分配责任时，他们将指向文档的某些部分并声称隐含了缺失的功能。或者他们会声称预期的功能显然超出了范围，因为文档某处隐藏了一句话。
Both groups know that a requirements specification for a project of any significance is too difficult to read and fully understand and impossible to write with the desired precision. So, whichever group writes the final requirements can claim ownership of the intent of the document. When the project is finished and blame is being allocated they will point to sections of the document and claim that missing features were implied. Or they will claim that expected functionality is clearly out of scope because of a sentence buried somewhere in the document.
大多数时候，当我看到两个小组编写本质上相同的文档的不同版本时，我已经知道他们将自己定位为项目结束时的责备会议并声称知道文档的意图。这种类型的愚蠢随着用户故事而消失。随着从文档到对话的转变，人们可以自由地知道没有什么是最终的。看起来像合同的文件感觉如此最终。谈话没有那种感觉。如果我们今天谈，然后下个月学到一些东西，我们再谈。
Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions and for claiming to know the intent of the document. This type of silliness goes away with user stories. Along with the shift to conversations from documentation comes the freedom of knowing that nothing is final. Documents that look like contracts feel so final. Conversations don’t feel that way. If we talk today and then learn something next month, we talk again.
我们可以思考、思考、思考一个计划好的系统，然后将所有需求写成“系统应该……”这听起来比“如果可能的话，系统将……”好得多。甚至“如果我们有时间，我们会尝试……”这更好地描述了大多数项目的现实情况。
There is a tremendous appeal to the idea that we can think, think, think about a planned system and then write all the requirements as “The system shall…” That sounds so much better than “if possible, the system will...” or even “if we have time, we’ll try to…” that better characterizes the reality on most projects.
不幸的是，实际上不可能以这种方式编写所有系统需求。当用户看到为他们构建的软件时，会出现一个强大而重要的反馈循环。当用户看到该软件时，他们会提出新的想法并改变他们对旧想法的看法。当要求对需求规范中描述的软件进行更改时，我们习惯于将其称为“范围更改”。这种想法是不正确的，原因有二。首先，它意味着该软件在某个时候因其范围而被认为是完全定义的而广为人知。无论在预先考虑需求方面付出了多少努力，我们了解到用户一旦看到该软件就会有不同（和更好）的意见。其次，这种想法强化了这样一种信念，即当软件满足一系列需求时，而不是当它实现其预期用户的目标时，软件就完成了。如果用户目标的范围发生变化，那么也许我们可以说“范围的变化，
Unfortunately, it is effectively impossible to write all of a system’s requirements this way. There is a powerful and important feedback loop that occurs when users see the software being built for them. When users see the software, they will come up with new ideas and change their minds about old ideas. When changes are requested to the software described in a requirements specification, we’ve become accustomed to calling it a “change of scope.” This type of thinking is incorrect for two reasons. First, it implies that the software was at some point sufficiently well-known for its scope to have been considered fully defined. It doesn’t matter how much effort is put into upfront thinking about requirements, we’ve learned that users will have different (and better) opinions once they see the software. Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills its intended users’ goals. If the scope of the user’s goals changes then perhaps we can speak of a “change of scope,” but the term is usually applied even when it is only the details of a specific software solution that have changed.
IEEE 830 风格的要求使许多项目误入歧途，因为它们将注意力集中在需求清单上，而不是用户的目标上。需求列表并不能像故事那样让读者对产品有同样的整体理解。阅读需求列表时如果不在脑海中自动考虑解决方案是非常困难的。Carroll (2000) 建议设计师“可以只针对他们遇到的前几个要求制定解决方案。” 例如，考虑以下要求：[1]
IEEE 830-style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user’s goals. Lists of requirements do not give the reader the same overall understanding of a product that stories do. It is very difficult to read a list of requirements without automatically considering solutions in your head as you read. Carroll (2000) suggests that designers “may produce a solution for only the first few requirements they encounter.” For example, consider the following requirements:[1]
3.4) 产品应配备汽油发动机。
3.4) The product shall have a gasoline-powered engine.
3.5) 产品应有四个轮子。
3.5) The product shall have four wheels.
3.5.1) 产品的每个车轮应安装一个橡胶轮胎。
3.5.1) The product shall have a rubber tire mounted to each wheel.
3.6) 产品应有方向盘。
3.6) The product shall have a steering wheel.
3.7) 产品应具有钢体。
3.7) The product shall have a steel body.
至此，我想汽车的图像已经浮现在您的脑海中。当然，汽车满足上面列出的所有要求。你脑海中的那个可能是一辆鲜红色的敞篷车，而我可能会想到一辆蓝色的皮卡。据推测，您的敞篷车和我的皮卡之间的差异包含在附加要求声明中。
By this point I suppose images of an automobile are floating around your head. Of course, an automobile satisfies all of the requirements listed above. The one in your head may be a bright red convertible while I might be envisioning a blue pickup. Presumably the differences between your convertible and my pickup are covered in additional requirements statements.
但是假设用户没有编写 IEEE 830 风格的需求规范，而是告诉我们她的产品目标：
But suppose that instead of writing an IEEE 830-style requirements specification, the user told us her goals for the product:
- 该产品让我可以轻松快捷地修剪草坪
- The product makes it easy and fast for me to mow my lawn
- 我在使用该产品时感觉很舒服
- I am comfortable while using the product
通过查看用户的目标，我们对产品有了完全不同的看法，并意识到客户真正想要的是骑乘式割草机，而不是汽车。这些目标不是用户故事，但 IEEE 830 文档是需求列表，故事描述了用户的目标。通过关注用户对新产品的目标，而不是新产品的一系列属性，我们能够设计出更好的解决方案来满足用户的需求。
By looking at the user’s goals, we get a completely different view of the product and realize that the customer really wants a riding lawn mower, not an automobile. These goals are not user stories, but where IEEE 830 documents are a list of requirements, stories describe a user’s goals. By focusing on the user’s goals for the new product, rather than a list of attributes of the new product, we are able to design a better solution to the user’s needs.
用户故事和 IEEE 830 风格的需求规范之间的最后一个区别是，对于后者，在所有需求都被写下来之前，每个需求的成本是不可见的。典型的场景是一位或多位分析师花费两三个月（通常更长）来编写一份冗长的需求文档。然后将其交给程序员，程序员告诉分析师（将消息传递给客户）该项目将耗时 24 个月，而不是他们希望的 6 个月。在这种情况下，团队没有时间开发的四分之三的时间被浪费在编写文档上，而且随着开发人员、分析师和客户迭代哪些功能可以及时开发，更多的时间将被浪费。对于故事，估算值与每个故事相关联。客户知道团队的速度和每个故事的故事点成本。在写了足够多的故事来填充所有迭代之后，她知道她已经完成了。
A final difference between user stories and IEEE 830-style requirements specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written down. The typical scenario is that one or more analysts spends two or three months (often longer) writing a lengthy requirements document. This is then handed to the programmers who tell the analysts (who relay the message to the customer) that the project will take twenty-four months, rather than the six months they had hoped for. In this case, time was wasted writing the three-fourths of the document that the team won’t have time to develop, and more time will be wasted as the developers, analysts and customer iterate over which functionality can be developed in time. With stories, an estimate is associated with each story right up front. The customer knows the velocity of the team and the story point cost of each story. After writing enough stories to fill all the iterations, she knows she’s done.
肯特·贝克 (Kent Beck) 用登记婚礼的类比来解释这种差异。[2]当您登记参加婚礼时，您看不到每件物品的费用。你只需列出你想要的一切。这可能适用于婚礼，但不适用于软件开发。当客户将一个项目放入她的项目愿望清单时，她需要知道它的成本。
Kent Beck explains this difference with an analogy of registering for a wedding.[2] When you register for a wedding you don’t see the cost of each item. You just make a wish list of everything you want. That may work for weddings, but it doesn’t work for software development. When a customer places an item on her project wish list, she needs to know the cost of it.
如何以及为何使用该功能？
需求列表的另一个问题是列表中的项目描述了软件的行为，而不是用户的行为或目标。需求列表很少回答“但是有人会如何以及为什么会使用此功能？”
A further problem with requirements lists is that the items on the lists describe the behavior of the software, not the behavior or goals of a user. A requirements list rarely answers “But how and why will someone use this feature?”
XP 开发人员和软件配置管理模式一书的作者 Steve Berczuk指出了这个问题的重要性：“我数不清有多少次我通过获取功能列表并要求客户创建来节省大量工作使用这些功能的场景。客户通常会意识到确实不需要该功能，而您应该花时间构建可以增加价值的东西。”[3]
Steve Berczuk, XP developer and author of Software Configuration Management Patterns, points out the importance of this question: “I can’t count the number of times that I saved a whole lot of work by taking a feature list and asking a customer to create scenarios that use those features. Often the customer will realize that the feature really isn’t needed, and that you should spend time building things that add value.”[3]
用户故事不是用例
User Stories Are Not Use Cases
由Ivar Jacobsen (1992)首次引入，如今用例最常与统一过程相关联。用例是对系统与一个或多个参与者之间的一组交互的概括描述，其中参与者是用户或另一个系统。用例可以用非结构化文本编写或符合结构化模板。Alistair Cockburn (2001)提出的模板是最常用的模板之一。示例如图 12.1所示，相当于用户故事“招聘人员可以使用信用卡支付职位发布费用。”
First introduced by Ivar Jacobsen (1992), use cases are today most commonly associated with the Unified Process. A use case is a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system. Use cases may be written in unstructured text or to conform with a structured template. The templates proposed by Alistair Cockburn (2001) are among the most commonly used. A sample is shown in Figure 12.1, which is equivalent to the user story “A Recruiter can pay for a job posting with a credit card.”
图 12.1。 职位发布薪酬的示例用例。
Figure 12.1. A sample use case for pay for a job posting.
由于这不是一本关于用例的书，我们不会完全涵盖图 12.1中显示的用例的所有细节；但是，值得回顾主要成功场景和扩展部分的含义。主要成功场景是对通过用例的主要成功路径的描述。在这种情况下，完成所示的五个步骤后就成功了。扩展部分定义了用例的替代路径。通常，扩展用于错误处理；但是，扩展也用于描述成功但次要的路径，例如图 12.1的扩展 3a 。通过用例的每条路径都称为场景. 因此，正如主要成功场景表示步骤 1 到 5 的顺序一样，备选场景由 1、2、2a、2a1、2、3、4、5 的顺序表示。
Since this is not a book on use cases we won’t fully cover all the details of the use case shown in Figure 12.1; however, it is worth reviewing the meaning of the Main Success Scenario and Extensions sections. The Main Success Scenario is a description of the primary successful path through the use case. In this case, success is achieved after completing the five steps shown. The Extensions section defines alternative paths through the use case. Often, extensions are used for error handling; but, extensions are also used to describe successful but secondary paths, such as in extension 3a of Figure 12.1. Each path through a use case is referred to as a scenario. So, just as the Main Success Scenario represents the sequence of steps one through five, an alternate scenario is represented by the sequence 1, 2, 2a, 2a1, 2, 3, 4, 5.
故事和用例之间最明显的区别之一是它们的范围。两者的大小都是为了提供业务价值，但故事的范围保持较小，因为我们对其大小施加了限制（例如不超过十天的开发工作），以便它们可以用于安排工作。用例几乎总是涵盖比故事大得多的范围。例如，查看用户故事“招聘人员可以使用信用卡支付招聘信息”，我们发现它类似于图 12.1的主要成功场景. 这导致观察到用户故事类似于用例的单个场景。每个故事不一定等同于一个主要的成功场景；例如，我们可以编写故事“当用户尝试使用过期的信用卡时，系统提示她输入另一张信用卡”，这相当于图 12.1的扩展 2b 。
One of the most obvious differences between stories and use cases is their scope. Both are sized to deliver business value, but stories are kept smaller in scope because we place constraints on their size (such as no more than ten days of development work) so that they may be used in scheduling work. A use case almost always covers a much larger scope than a story. For example, looking at the user story “A Recruiter can pay for a job posting with a credit card” we see it is similar to the main success scenario of Figure 12.1. This leads to the observation that a user story is similar to a single scenario of a use case. Each story is not necessarily equivalent to a main success scenario; for example, we could write the story “When a user tries to use an expired credit card the system prompts her to enter a different credit card,” which is equivalent to Extension 2b of Figure 12.1.
用户故事和用例的完整性级别也不同。James Grenning 指出，故事卡上的文本“加上验收测试基本上与用例相同。”[4] Grenning 的意思是故事对应于用例的主要成功场景，而故事的测试对应于用例的扩展。
User stories and use cases also differ in the level of completeness. James Grenning has noted that the text on a story card “plus acceptance tests are basically the same thing as a use case.”[4] By this Grenning means that the story corresponds to the use case’s main success scenario, and that the story’s tests correspond to the extensions of the use case.
例如，在第 6 章“验收测试用户故事”中，我们看到“招聘人员可以使用信用卡支付职位发布费用”故事的适当验收测试用例可能是：
For example, in Chapter 6, “Acceptance Testing User Stories,” we saw that appropriate acceptance test cases for the story “A Recruiter can pay for a job posting with a credit card” might be:
- 使用 Visa、MasterCard 和 American Express（通过）进行测试。
- Test with Visa, MasterCard and American Express (pass).
- 用 Diner's Club 测试（失败）。
- Test with Diner’s Club (fail).
- 使用好、坏和缺失的卡 ID 号进行测试。
- Test with good, bad and missing card ID numbers.
- 用过期的卡测试。
- Test with expired cards.
- 使用不同的购买金额（包括超过卡限额的金额）进行测试。
- Test with different purchase amounts (including one over the card’s limit).
查看这些验收测试，我们可以看到它们与图 12.1的扩展之间的相关性。
Looking at these acceptance tests we can see the correlation between them and the extensions of Figure 12.1.
用例和故事之间的另一个重要区别是它们的寿命。用例通常是永久性的工件，只要产品处于积极开发或维护状态，它们就会继续存在。另一方面，故事并不打算比它们被添加到软件中的迭代更长久。虽然可以存档故事卡，但许多团队只是将它们撕掉。
Another important difference between use cases and stories is their longevity. Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software. While it is possible to archive story cards, many teams simply rip them up.
另一个区别是用例更倾向于包含用户界面的细节，尽管有警告要避免这种情况（Cockburn 2001；Adolph、Bramble 等人 2002）。发生这种情况有几个原因。首先，用例通常会导致大量的纸张，并且没有其他合适的地方来放置用户界面需求，它们最终会出现在用例中。其次，用例编写者过早地关注软件实现而不是业务目标。
An additional difference is that use cases are more prone to including details of the user interface, despite admonishments to avoid this (Cockburn 2001; Adolph, Bramble, et al. 2002). There are several reasons this happens. First, use cases often lead to a large volume of paper and without another suitable place to put user interface requirements they end up in the use cases. Second, use case writers focus too early on the software implementation rather than on business goals.
包括用户界面细节会导致一定的问题，尤其是在新项目的早期，用户界面设计不应因先入之见而变得更加困难。我最近遇到了图 12.2中所示的用例，它描述了编写和发送电子邮件消息的步骤。
Including user interface details causes definite problems, especially early on in a new project when user interface design should not be made more difficult by preconceptions. I recently came across the use case shown in Figure 12.2, which describes the steps for composing and sending an email message.
图 12.2。 编写和发送电子邮件的用例。
Figure 12.2. A use case to compose and send an email message.
此用例始终具有用户界面假设。它假定有一个“新消息”菜单项，有一个用于编写新消息的对话框，该对话框上有主题和收件人输入字段，并且有一个发送按钮。这些假设中的许多可能看起来不错且安全，但它们可能会排除我单击收件人姓名以启动的用户界面消息而不是键入它。此外，图 12.2的用例排除了使用语音识别作为系统接口的可能性。
This use case has user interface assumptions throughout. It assumes that there is a “New Message” menu item, that there is a dialog for composing new messages, that there are subject and recipient input fields on that dialog, and that there is a Send button. Many of these assumptions may seem good and safe but they may rule out a user interface where I click on a recipient’s name to initiate the message instead of typing it in. Additionally, the use case of Figure 12.2 precludes the use of voice recognition as the interface to the system.
诚然，处理键入消息的电子邮件客户端比语音识别要多得多，但重点是用例不是指定这样的用户界面的合适位置。想一想将取代图 12.2的用户故事：“用户可以撰写和发送电子邮件。” 那里没有隐藏的用户界面假设。对于故事，用户界面将在与客户的对话中出现。
Admittedly, there are far more email clients that work with typed messages than with voice recognition, but the point is that a use case is not the proper place to specify the user interface like this. Think about the user story that would replace Figure 12.2: “A user can compose and send email messages.” No hidden user interface assumptions there. With stories, the user interface will come up during the conversation with the customer.
为了解决用例中用户界面假设的问题，Constantine 和 Lockwood (1999)建议使用基本用例。基本用例是已经去除了关于技术和实现细节的隐藏假设的用例。例如，表 12.1显示了编写和发送电子邮件的基本用例。基本用例的有趣之处在于用户意图可以直接解释为用户故事。
To get around the problem of user interface assumptions in use cases, Constantine and Lockwood (1999) have suggested the use of essential use cases. An essential use case is a use case that has been stripped of hidden assumptions about technology and implementation details. For example, Table 12.1 shows an essential use case for composing and sending an email message. What is interesting about essential use cases is that the user intentions could be directly interpreted as user stories.
另一个区别是用例和故事是为不同的目的而编写的 ( Davies 2001 )。用例以客户和开发人员都可以接受的格式编写，以便每个人都可以阅读并同意它们。他们的目的是记录客户和开发团队之间的协议。另一方面，编写故事是为了促进发布和迭代计划，并充当有关用户详细需求的对话的占位符。
Another difference is that use cases and stories are written for different purposes (Davies 2001). Use cases are written in a format acceptable to both customers and developers so that each may read and agree to them. Their purpose is to document an agreement between the customer and the development team. Stories, on the other hand, are written to facilitate release and iteration planning, and to serve as placeholders for conversations about the users’ detailed needs.
表 12.1。 一个重要的用例。
Table 12.1. An essential use case.
并不是所有的用例都是填表写的，如图12.1所示。一些用例被写成非结构化文本。Cockburn 将这些称为用例简报。用例简介在两个方面不同于用户故事。首先，由于用例简介必须涵盖与用例相同的范围，因此用例简介的范围通常大于用户故事的范围。也就是说，一个用例简介通常会讲述多个故事。其次，用例简介旨在伴随产品的整个生命周期。另一方面，用户故事被处理掉了。
Not all use cases are written by filling in a form, as shown in Figure 12.1. Some use cases are written as unstrucutred text. Cockburn refers to these as use case briefs. Use case briefs differ from user stories in two ways. First, since a use case brief must still cover the same scope as a use case, the scope of a use case brief is usually larger than the scope of a user story. That is, one use case brief will typically tell more than one story. Second, use case briefs are intended to live on for the life of a product. User stories, on the other hand, are disposed of.
最后，用例通常作为分析活动的结果编写，而用户故事则作为注释编写，可用于启动分析对话。
Finally, use cases are generally written as the result of an analysis activity, while user stories are written as notes that can be used to initiate analysis conversations.
用户故事不是场景
User Stories Aren’t Scenarios
除了指代通过用例的单一路径外，人机交互设计师也使用场景这个词。在此上下文中，场景是对用户与计算机交互的详细描述。交互设计的场景与用例的场景不同。事实上，交互设计场景通常比用例更大或更全面。例如，考虑这种情况：
In addition to referring to a single path through a use case, the word scenario is also used by human-computer interaction designers. In this context a scenario is a detailed description of a user’s interaction with a computer. The scenarios of interaction design are not the same as a scenario of a use case. In fact, an interaction design scenario is typically larger, or more encompassing, than even a use case. For example, consider this scenario:
玛丽亚正在考虑改变职业。自互联网繁荣的辉煌岁月以来，她一直在 BigTechCo 担任测试员。玛丽亚曾是一名高中数学老师，她认为如果回到教学岗位她会更快乐。Maria 访问 BigMoneyJobs.com 网站。她使用用户名和密码创建了一个新帐户。然后她创建了她的简历。她想在爱达荷州的任何地方找一份数学老师的工作，但最好是在她目前在科达伦的工作附近。玛丽亚找到了一些符合她搜索条件的工作。最吸引她的工作是在博伊西的一所私立高中北岸学校。玛丽亚在博伊西有一个朋友杰西卡，她希望她能认识北岸的某个人。Maria 输入 Jessica 的电子邮件地址，并将工作链接转发给她，并附上一张便条，询问她是否认识学校里的任何人。第二天早上，玛丽亚收到杰西卡的一封电子邮件，说她在学校不认识任何人，但她知道北岸学校，而且它的名声很好。Maria 单击一个按钮，将她的简历提交给 North Shore。
Maria is thinking about making a career change. Since the glory days of the dot-com boom she has worked as a tester at BigTechCo. A former high school math teacher, Maria decides she’ll be happier if she returns to teaching. Maria goes to the BigMoneyJobs.com website. She creates a new account with a user name and password. She then creates her resume. She wants to find a job as a math teacher anywhere in Idaho but preferably near her current job in Coeur d’Alene. Maria finds a handful of jobs that match her search criteria. The job that intrigues her most is with the North Shore School, a private high school in Boise. Maria has a friend, Jessica, in Boise whom she hopes may know someone at North Shore. Maria enters Jessica’s email address and forwards the job link to her with a note asking if she knows anyone at the school. The next morning Maria gets an email from Jessica saying that she doesn’t know anyone at the school, but she knows of the North Shore School and it has a wonderful reputation. Maria clicks on a button that submits her resume to North Shore.
Carroll (2000) 说场景包括以下特征元素：
Carroll (2000) says that scenarios include the following characteristic elements:
- 一个设置
- a setting
- 演员
- actors
- 目标或目的
- goals or objectives
- 行动和事件
- actions and events
场景是故事发生的地点。在关于玛丽亚的故事中，故事大概发生在她的家用电脑上；但由于没有说明，故事发生的地点可能是她工作日的办公室。
The setting is the location where the story takes place. In the story about Maria the story presumably takes place on her home computer; but since that is not stated, the location of the story could be her office during the workday.
每个场景包括至少一个演员。一个场景可能有多个参与者。例如，在我们的场景中，Maria 和 Jessica 都是演员。玛丽亚可能被称为主要演员，因为场景主要描述了她与系统的交互。但是，因为杰西卡收到系统发来的邮件，然后使用网站查看招聘信息，所以她被认为是次要演员。与用例不同，交互设计场景中的参与者始终是人，而不是其他系统。
Each scenario includes at least one actor. It is possible for a scenario to have multiple actors. For example, in our scenario both Maria and Jessica are actors. Maria may be referred to as the primary actor because the scenario mostly describes her interactions with the system. However, because Jessica receives an email from the system and then uses the website to look at the job posting, she is considered a secondary actor. Unlike use cases, actors in interaction design scenarios are always people and never other systems.
场景中的每个参与者都在追求一个或多个目标。与演员一样，可以有主要目标和次要目标。例如，Maria 的主要目标是在她想要的位置找到一份合适的工作。在努力实现该目标的同时，她还追求次要目标，例如查看有关酒店的详细信息或与朋友分享信息。
Each actor in a scenario is pursuing one or more goals. As with actors, there can be primary and secondary goals. For example, Maria’s primary goal is to find an appropriate job in her desired location. While working to achieve that goal, she pursues secondary goals such as viewing detailed information about a hotel or sharing information with a friend.
卡罗尔将行动和事件称为情景情节。它们是参与者为实现其目标或系统响应而采取的步骤。在爱达荷州找工作是 Maria 执行的一项操作。对该操作的响应是系统显示匹配作业列表的事件。
Carroll refers to the actions and events as the plot of a scenario. They are the steps an actor takes to achieve her goal or a system’s response. Searching for a job in Idaho is an action Maria performs. The response to that action is the event of the system displaying a list of matching jobs.
用户故事和场景之间的主要区别在于范围和细节。场景包含更多细节，它们的范围通常涵盖多个故事。示例场景包含许多可能的故事，例如：
The primary differences between user stories and scenarios are scope and detail. Scenarios contain much more detail and their scope usually covers multiple stories. The example scenario contains many possible stories, such as:
- 用户可以通过电子邮件将工作信息发送给朋友
- a user can send information about a job to a friend via email
- 用户可以创建简历
- a user can create a resume
- 用户可以为匹配的工作提交她的简历
- a user can submit her resume for a matching job
- 用户可以按地理区域搜索工作
- a user can search for a job by geographic region
即使有额外的细节，场景（如故事）也会留下需要在讨论中解决的细节。例如：
Even with their additional detail, scenarios (like stories) leave details to be worked through in a discussion. For example:
- Maria 使用用户名和密码登录该站点。是否所有用户都必须登录网站？或者登录是否启用了 Maria 使用的某些功能（也许是发送电子邮件的功能）？
- Maria logged onto the site with a user name and password. Are all users required to log onto the site? Or does logging on enable some of the features Maria used (perhaps the feature to send an email)?
- 当 Jessica 收到电子邮件时，电子邮件是否包含有关工作的信息，还是仅链接到包含该信息的网站页面？
- When Jessica receives the email, does the email contain information about the job or does it just link to a page on the site with that information?
概括
Summary
- 用户故事不同于 IEEE 830 软件需求规范、用例和交互设计场景。
- User stories are different from IEEE 830 software requirements specifications, use cases and interaction design scenarios.
- 无论我们做多少思考、思考和思考，我们都无法预先完全、完美地指定一个非平凡的系统。
- No matter how much thinking, thinking and thinking we do, we cannot fully and perfectly specify a non-trivial system upfront.
- 在定义需求和用户能够及早和频繁地访问软件之间存在一个有价值的反馈循环。
- There is a valuable feedback loop that occurs between defining requirements and users having early and frequent access to the software.
- 考虑用户的目标比列出解决方案的属性更重要。
- It is more important to think about users’ goals than to list the attributes of a solution.
- 用户故事类似于用例场景。但是用例仍然往往比单个故事更大，并且更倾向于包含有关用户界面的嵌入式假设。
- User stories are similar to a use case scenario. But use cases still tend to be larger than a single story and can be more prone to containing embedded assumptions about the user interface.
- 此外，用户故事在完整性和寿命方面与用例不同。用例比用户故事更完整。用例被设计为开发过程的永久工件；用户故事更短暂，不会比开发它们的迭代更长久。
- Additionally, user stories differ from use cases in their completeness and longevity. Use cases are much more complete than are user stories. Use cases are designed to be permanent artifacts of the development process; user stories are more transient and not intended to outlive the iteration in which they are developed.
- 用户故事和用例是为不同的目的而编写的。编写用例是为了让开发人员和客户可以讨论并同意它们。编写用户故事是为了促进发布计划，并作为提醒以通过对话填写需求详细信息。
- User stories and use cases are written for different purposes. Use cases are written so that developers and customers can discuss them and agree to them. User stories are written to facilitate release planning and to serve as reminders to fill in requirements details with conversations.
- 与 IEEE 830 规范和用例不同，用户故事不是分析活动的产物。相反，用户故事是分析的支持工具。
- Unlike IEEE 830 specifications and use cases, user stories are not artifacts of analysis activities. Rather, user stories are a support tool for analysis.
- 交互设计场景比用户故事更详细，并且在提供的细节类型上有所不同。
- Interaction design scenarios are much more detailed than user stories and differ in the kind of detail provided.
- 典型的交互设计场景比用户故事大得多。一个场景可能包含多个用例，而这些用例又可能包含许多用户故事。
- A typical interaction design scenario is much larger than a user story. One scenario may comprise multiple use cases, which, in turn, may comprise many user stories.
问题
Questions
12.1用户故事和用例之间的主要区别是什么？
12.1 What are the key differences between user stories and use cases?
12.2用户故事和 IEEE 830 需求陈述之间的主要区别是什么？
12.2 What are the key differences between user stories and IEEE 830 requirements statements?
12.3用户故事和交互设计场景之间的主要区别是什么？
12.3 What are the key differences between user stories and interaction design scenarios?
12.4对于一个非平凡的项目，为什么不可能在项目开始时就写完所有的需求？
12.4 For a non-trivial project, why is it impossible to write all the requirements at the start of the project?
12.5考虑用户的目标比列出要构建的软件的属性有什么好处？
12.5 What is the advantage to thinking about users’ goals rather than on listing the attributes of the software to be built?
第 13 章为什么要使用用户故事？
Chapter 13. Why User Stories?
有了所有可用的考虑需求的方法，我们为什么要选择用户故事？本章着眼于用户故事相对于替代方法的以下优势：
With all of the available methods for considering requirements, why should we choose user stories? This chapter looks at the following advantages of user stories over alternative approaches:
- 用户故事强调口头交流。
- User stories emphasize verbal communication.
- 每个人都可以理解用户故事。
- User stories are comprehensible by everyone.
- 用户故事的大小适合规划。
- User stories are the right size for planning.
- 用户故事适用于迭代开发。
- User stories work for iterative development.
- 用户故事鼓励推迟细节。
- User stories encourage deferring detail.
- 用户故事支持机会主义设计。
- User stories support opportunistic design.
- 用户故事鼓励参与式设计。
- User stories encourage participatory design.
- 用户故事建立了隐性知识。
- User stories build up tacit knowledge.
在考虑了用户故事相对于替代方法的优势之后，本章最后指出了用户故事的一些潜在缺点。
After having considered the advantages of user stories over alternative approaches, the chapter concludes by pointing out a few potential drawbacks to user stories.
口头交流
Verbal Communication
人类曾有如此奇妙的口述传统；神话和历史是一代又一代口口相传的。直到一位雅典统治者开始写下荷马的《伊利亚特》以防止遗忘，像荷马这样的故事才被讲述，而不是被阅读。那时我们的记忆力一定要好得多，并且一定是在 1970 年代的某个时候开始褪色，因为到那时我们甚至连“系统将提示用户输入登录名和密码”这样的简短语句都记不住了。所以，我们开始把它们写下来。
Humans used to have such a marvelous oral tradition; myths and history were passed orally from one generation to the next. Until an Athenian ruler started writing down Homer’s The Iliad so that it would not be forgotten, stories like Homer’s were told, not read. Our memories must have been a lot better back then and must have started to fade sometime in the 1970s because by then we could no longer remember even short statements like “The system shall prompt the user for a login name and password.” So, we started writing them down.
这就是我们开始出错的地方。我们将重点转移到共享文档上，而不是共享理解上。
And that’s where we started to go wrong. We shifted focus to a shared document and away from a shared understanding.
似乎很容易想到，如果一切都写下来并达成一致，那么就不会有分歧，开发人员将确切地知道要构建什么，测试人员将确切地知道如何测试它，最重要的是，客户将得到他们想要的东西通缉。嗯，不，那是错误的：客户将得到开发人员对所写内容的解释，这可能并不完全是他们想要的。
It seems so easy to think that if everything is written down and agreed to then there can be no disagreements, developers will know exactly what to build, testers will know exactly how to test it, and, most importantly, customers will get exactly what they wanted. Well, no, that’s wrong: Customers will get the developers’ interpretation of what was written down, which may not be exactly what they wanted.
在尝试之前，写下一堆软件需求并让一组开发人员构建您想要的东西似乎很简单。但是，如果我们在编写足够精确的午餐菜单时遇到困难，请想一想编写软件需求该有多难。前几天午餐时，我的菜单上写着：
Until trying it, it would seem simple enough to write down a bunch of software requirements and have a team of developers build exactly what you want. However, if we have trouble writing a lunch menu with sufficient precision, think how hard it must be to write software requirements. At lunch the other day my menu read:
主菜可选择汤或沙拉和面包。
Entrée comes with choice of soup or salad and bread.
这不应该是一个难以理解的句子，但确实如此。这意味着我可以选择其中的哪一个？
That should not have been a difficult sentence to understand but it was. Which of these did it mean I could choose?
汤或（沙拉和面包）
（汤或沙拉）和面包
Soup or (Salad and Bread)
(Soup or Salad) and Bread
我们常常表现得好像书面文字是精确的，但事实并非如此。将菜单上的文字与女服务员的口语进行对比：“你想要汤还是沙拉？” 更好的是，她在接受我的订单之前将一篮子面包放在桌子上，从而消除了所有歧义。
We often act as though written words are precise, yet they aren’t. Contrast the words written on that menu with the waitress’ spoken words: “Would you like soup or salad?” Even better, she removed all ambiguity by placing a basket of bread on the table before she took my order.
同样糟糕的是，单词可以有多种含义。作为一个极端的例子，请考虑以下两个句子：
Just as bad is that words can take on multiple meanings. As an extreme example, consider these two sentences:
水牛水牛水牛。
水牛水牛 水牛水牛。
Buffalo buffalo buffalo.
Buffalo buffalo Buffalo buffalo.
哇。这些句子可能意味着什么？Buffalo 可以表示大型毛茸茸的动物（也称为野牛）或纽约的城市，也可以表示“恐吓”，如“开发商被 buffaloed 承诺提前交货”。所以，第一句话的意思是bison intimidate other bison。第二句意思是bison intimidate bison from the city of Buffalo。
Wow. What can those sentences possibly mean? Buffalo can mean either the large furry animal (also known as a bison), or a city in New York, or it can mean “intimidate,” as in “The developers were buffaloed into promising an earlier delivery date.” So, the first sentences means that bison intimidate other bison. The second sentence means that bison intimidate bison from the city of Buffalo.
除非我们正在为野牛编写软件，否则这是一个公认的不太可能的例子；但它真的比这个典型的需求声明差得多吗：
Unless we’re writing software for bison this is an admittedly unlikely example; but is it really much worse than this typical requirements statement:
- 每当用户输入无效数据时，系统应显着显示警告消息。
- The system should prominently display a warning message whenever the user enters invalid data.
是否应该意味着如果我们愿意，可以忽略该要求？我应该每天吃三份蔬菜；我不。突出显示是什么意思？对于编写此代码的人来说突出的内容可能对编码和测试它的人来说并不突出。
Does should mean the requirement can be ignored if we want? I should eat three servings of vegetables a day; I don’t. What does prominently display mean? What’s prominent to whoever wrote this may not be prominent to whoever codes and tests it.
再举一个例子，我最近遇到了这个要求，它指的是用户在数据管理系统中命名文件夹的能力：
As another example, I recently came across this requirement that was referring to a user’s ability to name a folder in a data management system:
- 用户可以输入名称。它可以是 127 个字符。
- The user can enter a name. It can be 127 characters.
从这个声明中不清楚用户是否必须输入文件夹的名称。可能为该文件夹提供了默认名称。第二句话几乎完全没有意义。文件夹名称可以是其他长度还是必须始终为 127 个字符？
From this statement it is not clear if the user must enter a name for the folder. Perhaps a default name is provided for the folder. The second sentence is almost completely meaningless. Can the folder name be another length or must it always be 127 characters?
把事情写下来确实有好处：书面文字有助于克服短期记忆、分心和干扰的局限性。但是，如果我们将重点从编写需求转移到谈论需求，那么许多混淆的来源——无论是来自书面文字的不精确性还是来自具有多重含义的词语——都会消失。
Writing things down does have advantages: written words help overcome the limitations of short-term memory, distractions, and interruptions. But, so many sources of confusion—whether from the imprecision of written words or from words with multiple meanings—go away if we shift the focus from writing requirements down to talking about them.
自然地，我们语言的一些问题既存在于口头交流中，也存在于书面交流中；但是当客户、开发人员和用户交谈时，就有机会形成一个简短的反馈循环，从而导致相互学习和理解。谈话不会像书面文字那样假装精确和准确。没有人在对话上签字，也没有人指着它说，“就在那里，三个月前的一个星期二，你说密码不能包含数字。”
Naturally, some of the problems of our language exist with verbal as well as with written communication; but when customers, developers and users talk there is the opportunity for a short feedback loop that leads to mutual learning and understanding. With conversations there is not the false appearance of precision and accuracy that there is with written words. No one signs off on a conversation and no one points to it and says, “Right there, three months ago on a Tuesday, you said passwords could not contain numbers.”
我们对用户故事的目标不是记录有关所需功能的每一个细节；相反，它是写下一些简短的占位句，以提醒开发人员和客户进行未来的对话。我的许多谈话都是通过电子邮件进行的，没有它我就无法完成我的工作。我每天发送和接收数百封电子邮件。但是，当我需要与某人讨论一些复杂的事情时，我总是会拿起电话或步行到对方的办公室或工作区。
Our goal with user stories is not to document every last detail about a desired feature; rather, it is to write down a few short placeholding sentences that will remind developers and customers to hold future conversations. Many of my conversations occur through email and I couldn’t possibly do my job without it. I send and receive hundreds of emails every day. But, when I need to talk to someone about something complicated, I invariably pick up the phone or walk to the person’s office or workspace.
最近召开的传统需求工程会议包括关于编写“完美需求”的半天教程，并承诺教授编写更好的句子以实现完美需求的技巧。编写完美的需求似乎是一个崇高而遥不可及的目标。
A recent conference on traditional requirements engineering included a half-day tutorial on writing “perfect requirements” and promised to teach techniques for writing better sentences to achieve perfect requirements. Writing perfect requirements seems like such a lofty and unattainable goal.
即使需求文档中的每一句话都很完美，仍然存在两个问题。首先，用户会随着对正在开发的软件了解更多而完善他们的意见。其次，不能保证这些完美部分的总和就是一个完美的整体。Tom Poppendieck 提醒我，100 只完美的左脚鞋并不能换来一双完美的鞋。远比完美的要求更有价值的目标是通过频繁的对话来增加足够的故事。
And even if each sentence in a requirements document is perfect, there are still two problems. First, users will refine their opinions as they learn more about the software being developed. Second, there is no guarantee that the sum of these perfect parts is a perfect whole. Tom Poppendieck has reminded me that 100 perfect left shoes does not yield a single perfect pair of shoes. A far more valuable goal than perfect requirements is to augment adequate stories with frequent conversations.
用户故事是可以理解的
User Stories Are Comprehensible
与 IEEE 830 风格的软件需求规范相比，用例和场景带给我们的优势之一是用户和开发人员都可以理解它们。IEEE 830 风格的文档通常包含太多用户无法阅读的技术术语，以及太多开发人员无法阅读的特定领域术语。
One of the advantages that use cases and scenarios bring us over IEEE 830-style software requirements specifications is that they are understandable by both users and developers. IEEE 830-style documents often contain too much technical jargon to be readable by users and too much domain-specific jargon to be readable by developers.
故事更进一步，甚至比用例或场景更易于理解。Constantine 和 Lockwood (1999)观察到，强调场景的真实性和细节会导致场景掩盖更广泛的问题。这使得在处理场景时更难理解交互的基本性质。因为故事很简洁，而且总是为了展示客户或用户的价值而编写，所以它们总是很容易被业务人员和开发人员理解。
Stories take this further and are even more comprehensible than use cases or scenarios. Constantine and Lockwood (1999) have observed that the emphasis scenarios place on realism and detail can cause scenarios to obscure broader issues. This makes it more difficult when working with scenarios to understand the basic nature of the interactions. Because stories are terse and are always written to show customer or user value, they are always readily comprehensible by business people and developers.
此外，70 年代后期的一项研究发现，如果将事件组织成故事，人们就能更好地记住事件（Bower、Black 和 Turner 1979）。更好的是，研究参与者对陈述的动作和推断的动作都有更好的回忆。也就是说，故事不仅有助于回忆陈述的动作，还有助于回忆未陈述的动作。我们写的故事可以比传统的需求规范甚至用例更简洁，而且因为它们是作为故事来写和讨论的，所以回忆起来会更大。
Additionally, a study in the late 1970s found that people are better able to remember events if they are organized into stories (Bower, Black and Turner 1979). Even better, study participants had better recall of both stated actions as well as inferred actions. That is, not only do stories facilitate recall of stated actions, they facilitate recall of the unstated actions. The stories we write can be more terse than traditional requirements specifications or even use cases, and because they are written and discussed as stories, recall will be greater.
用户故事是规划的合适规模
User Stories Are the Right Size for Planning
此外，用户故事的大小适合规划——不太大，也不太小，但恰到好处。在大多数开发人员职业生涯的某个时刻，有必要要求客户或用户确定 IEEE 830 类需求的优先级。通常的结果是大约 90% 的要求是强制性的，5% 是非常可取的，但可以暂时推迟，另外 5% 的要求可以推迟一段时间。这是因为很难对成千上万个以“系统应……”开头的句子进行优先排序和处理。例如，请考虑以下示例需求：
Additionally, user stories are the right size for planning—not too big, not too small, but just right. At some point in the career of most developers it has been necessary to ask a customer or user to prioritize IEEE 830-style requirements. The usual result is something like 90% of the requirements are mandatory, 5% are very desirable but can be deferred briefly, and another 5% may be deferred a bit longer. This is because it’s hard to prioritize and work with thousands of sentences all starting with “The system shall…” For example, consider the following sample requirements:
4.6) The system shall allow a room to be reserved with a credit card.
4.6.1) 系统应接受维萨卡、万事达卡和美国运通卡。
4.6.1) The system shall accept Visa, MasterCard and American Express cards.
4.6.1.1) 系统应验证卡未过期。
4.6.1.1) The system shall verify that the card has not expired.
4.6.2) 系统将在预订确认前从信用卡中收取所有住宿晚数的费用。
4.6.2) The system shall charge the credit card the indicated rate for all nights of the stay before the reservation is confirmed.
4.7) 系统会给予用户一个唯一的确认号码。
4.7) The system shall give the user a unique confirmation number.
IEEE 830 要求规范中的每一层嵌套都表明了要求陈述之间的关系。在上面的示例中，认为客户可以将 4.6.1.1 与 4.6.1 分开优先考虑是不现实的。如果项目不能区分优先级或单独开发，也许它们不应该写成单独的项目。如果它们只是单独编写以便每个都可以被离散测试，那么直接编写测试会更好。
Each level of nesting within an IEEE 830 requirements specification indicates a relationship between the requirements statements. In the example above, it is unrealistic to think that a customer could prioritize 4.6.1.1 separately from 4.6.1. If items cannot be prioritized or developed separately, perhaps they shouldn’t be written as separate items. If they are only written separately so that each may be discretely tested, it would be better to just write the tests directly.
当您考虑典型产品的软件需求规范（以及它们之间的关系）中的数千或数万条陈述时，很容易看出对它们进行优先级排序的内在困难。
When you consider the thousands or tens of thousands of statements in a software requirements specification (and the relationships between them) for a typical product, it is easy to see the inherent difficulty in prioritizing them.
用例和交互设计场景遇到了相反的问题——它们太大了。对几十个用例或场景进行优先排序有时很容易，但结果通常没有用，因为很少有所有最高优先级项目都比所有第二优先级项目更重要的情况。许多项目试图通过编写许多较小的用例来纠正这个问题，结果他们在那个方向上摇摆不定。
Use cases and interaction design scenarios suffer from the opposite problem—they’re just too big. Prioritizing a few dozen use cases or scenarios is sometimes easy but the results are often not useful because it is rarely the case that all of the top priority items are more important than all of the second priority items. Many projects have tried to correct this by writing many smaller use cases with the result that they swing too far in that direction.
另一方面，故事的大小是可管理的，因此它们可以方便地用于规划发布，以及供开发人员用于编程和测试。
Stories, on the other hand, are of a manageable size such that they may be conveniently used for planning releases, and by developers for programming and testing.
用户故事为迭代开发工作
User Stories Work for Iterative Development
用户故事还具有与迭代开发兼容的巨大优势。在开始编写第一个代码之前，我不需要写完所有故事。我可以写一些故事，编码并测试这些故事，然后根据需要经常重复。在写故事时，我可以在任何适当的细节层次上写它们。故事很适合迭代开发，因为迭代故事本身是多么容易。
User stories also have the tremendous advantage that they are compatible with iterative development. I do not need to write all of my stories before I begin coding the first. I can write some stories, code and test those stories, and then repeat as often as necessary. When writing stories I can write them at whatever level of detail is appropriate. Stories work well for iterative development because of how easy it is to iterate over the stories themselves.
例如，如果我刚刚开始考虑一个项目，我可能会写一些史诗般的故事，比如“用户可以撰写和发送电子邮件”。这可能恰好适合非常早的计划。稍后我会把这个故事分成十几个其他故事：
For example, if I’m just starting to think about a project, I may write epic stories like “the user can compose and send email.” That may be just right for very early planning. Later I’ll split that story into perhaps a dozen other stories:
- 用户可以撰写电子邮件。
- A user can compose an email message.
- 用户可以在电子邮件消息中包含图形。
- A user can include graphics in email messages.
- 用户可以发送电子邮件消息。
- A user can send email messages.
- 用户可以安排在特定时间发送电子邮件。
- A user can schedule an email to be sent at a specific time.
场景和 IEEE 830 文档不适合这种类型的渐进式详细信息。按照它们的书写方式，IEEE 830 文档暗示如果没有声明“系统应...”，则假定系统不会。这使得无法知道需求是否缺失或只是尚未编写。
Scenarios and IEEE 830 documents do not lend themselves to this type of progressive levels of detail. By the way they are written, IEEE 830 documents imply that if there is no statement saying “The system shall…” then it is assumed that the system shall not. This makes it impossible to know if a requirement is missing or simply has not been written yet.
情景的力量在于它们的细节。因此，在没有细节的情况下开始一个场景，然后根据开发人员的需要逐步添加细节的想法是没有意义的，并且会完全剥夺场景的用处。
The power of scenarios is in their detail. So, the idea of starting a scenario without detail and then progressively adding detail as it is needed by the developers makes no sense and would strip scenarios of their usefulness entirely.
用例可以在不同的渐进详细级别上编写，Cockburn (2001)提出了这样做的极好方法。然而，大多数组织并没有使用自由格式的文本来编写用例，而是定义了一个标准模板。然后，该组织要求所有用例都符合该模板。当许多人觉得有必要填写表格上的每个空格时，这就会成为一个问题。Fowler (1997)将此称为完全主义。在实践中，很少有组织能够编写一些概括级别的用例和一些详细级别的用例。用户故事很适合完成者，因为到目前为止，还没有人提出要为每个故事编写的字段模板。
Use cases can be written at varying progressive levels of detail, and Cockburn (2001) has suggested excellent ways of doing so. However, rather than writing use cases with free-form text, most organizations define a standard template. The organization then mandates that all use cases conform to the template. This becomes a problem when many people feel compelled to fill in each space on a form. Fowler (1997) refers to this as completism. In practice, few organizations are able to write some use cases at a summary level and some at a detailed level. User stories work well for completists because—so far—no one has proposed a template of fields to be written for each story.
故事鼓励推迟细节
Stories Encourage Deferring Detail
故事还有一个好处，那就是它们鼓励团队推迟收集细节。可以编写一个初始的占位目标级别的故事（“招聘人员可以发布新的职位空缺”），然后在了解细节变得重要时用更多细节替换。
Stories also have the advantage that they encourage the team to defer collecting details. An initial place-holding goal-level story (“A Recruiter can post a new job opening”) can be written and then replaced with more details once it becomes important to have the details.
这使得用户故事非常适合时间受限的项目。一个团队可以非常快速地编写几十个故事来让他们对系统有一个整体的感觉。然后，他们可以深入了解一些故事的细节，并且可以比感觉被迫完成 IEEE 830 式软件需求规范的团队更快地编写代码。
This makes user stories perfect for time-constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830-style software requirements specification.
故事支持机会主义发展
Stories Support Opportunistic Development
人们很容易相信我们可以写下系统的所有需求，然后以自上而下的方式思考解决方案。将近二十年前，Parnas 和 Clements (1986)告诉我们，我们永远不会看到这样的项目，因为：
It is tempting to believe that we can write down all of the requirements for a system and then think our way to a solution in a top-down manner. Nearly two decades ago Parnas and Clements (1986) told us that we will never see a project work this way, because:
- 用户和客户通常并不确切知道他们想要什么。
- Users and customers do not generally know exactly what they want.
- 即使软件开发人员知道所有需求，他们开发软件所需的许多细节只有在开发系统时才会变得清晰。
- Even if the software developers know all the requirements, many of the details they need to develop the software become clear only as they develop the system.
- 即使事先知道所有细节，人类也无法理解那么多细节。
- Even if all the details could be known up front, humans are incapable of comprehending that many details.
- 即使我们能够了解所有细节，产品和项目也会发生变化。
- Even if we could understand all the details, product and project changes occur.
- 人们会犯错误。
- People make mistakes.
如果我们不能以严格自上而下的方式构建软件，那么我们如何构建软件呢？Guindon (1990)研究了软件开发人员如何思考问题。她向一小组软件开发人员提出了设计建筑物电梯控制系统的问题。然后，她拍摄并观察了开发人员解决问题的过程。她发现开发人员根本没有遵循自上而下的方法。相反，开发人员采用了一种机会主义的方法，在这种方法中，他们在考虑需求、发明和讨论使用场景以及在不同抽象级别进行设计之间自由移动。当开发人员发现有机会从转换他们的思维中获益时，他们很乐意这样做。
If we can’t build software in a strictly top-down manner, then how do we build software? Guindon (1990) studied how software developers think about problems. She presented a small set of software developers with a problem in designing an elevator control system for a building. She then videotaped and observed the developers as they worked through the problem. What she found was that the developers did not follow a top-down approach at all. Rather, the developers followed an opportunistic approach in which they moved freely between considering the requirements to inventing and discussing usage scenarios, to designing at various levels of abstraction. As the developers perceived opportunities to benefit from shifting their thinking between, they readily did so.
故事承认并克服了帕纳斯和克莱门茨提出的问题。通过他们对对话的严重依赖以及他们在不同细节层次上轻松编写和重写的能力，故事提供了一个解决方案：
Stories acknowledge and overcome the problems raised by Parnas and Clements. Through their heavy reliance on conversation and their ability to be easily written and rewritten at varying levels of detail, stories provide a solution:
- 这不依赖于用户提前充分了解和传达他们的确切需求
- that is not reliant on users fully knowing and communicating their exact needs in advance
- 这不依赖于开发人员能够完全理解大量的细节
- that is not reliant on developers being able to fully comprehend a vast array of details
- 拥抱变化
- that embraces change
从这个意义上说，故事承认软件必须机会主义地开发。由于不可能有从高级需求到代码的严格线性路径进行的过程，用户故事很容易让团队在高层次和低层次的思考和讨论需求之间转换。
In this sense, stories acknowledge that software must be developed opportunistically. Since there can be no process that proceeds in a strictly linear path from high-level requirements to code, user stories easily allow a team to shift between high- and low-levels of thinking and talking about requirements.
用户故事鼓励参与式设计
User Stories Encourage Participatory Design
故事和场景一样，引人入胜。将焦点从谈论系统的属性转移到关于用户使用系统的目标的故事会导致关于系统的更有趣的讨论。由于缺乏用户参与，许多项目都失败了；故事是吸引用户参与其软件设计的一种简单方法。
Stories, like scenarios, are engaging. Shifting the focus from talking about the attributes of a system to stories about users’ goals for using the system leads to more interesting discussions about the system. Many projects have failed because of a lack of user participation; stories are an easy way to engage users as participants in the design of their software.
在参与式设计（Kuhn 和 Muller 1993；Schuler 和 Namioka 1993）中，系统的用户成为设计其软件行为的团队的一部分。他们不是通过管理法令（“你应该组建一个跨职能团队并包括用户”）成为团队的一部分；相反，用户成为团队的一部分，因为他们非常关注所使用的需求和设计技术。例如，在参与式设计中，用户从一开始就协助用户界面的原型制作。只有在初始原型可供查看后，他们才参与进来。
In participatory design (Kuhn and Muller 1993; Schuler and Namioka 1993) the users of a system become a part of the team designing the behavior of their software. They do not become a part of the team through management edict (“Thou shalt form a cross-functional team and include the users”); rather, the users become part of the team because they are so engaged by the requirements and design techniques in use. In participatory design, for example, users assist in the prototyping of the user interface from the beginning. They are not involved only after an initial prototype is available for viewing.
与参与式设计相对的是实证设计，在这种设计中，新软件的设计者通过研究潜在用户和软件的使用情况来做出决定。实证设计在很大程度上依赖于访谈和观察，但用户并没有成为软件设计的真正参与者。
Standing in contrast to participatory design is empirical design, in which the designers of new software make decisions by studying the prospective users and the situations in which the software will be used. Empirical design relies heavily on interview and observation but users do not become true participants in the design of the software.
因为用户故事和场景完全没有技术术语，所以它们对用户和客户来说是完全可以理解的。虽然写得很好的用例可能会避免技术术语，但用例的读者通常必须学习如何解释用例的格式。很少有用例的初次阅读者对用例形式上的公共字段（如扩展、前提条件和保证）有隐含的理解。典型的 IEEE 830 文档既包含技术术语，又存在理解冗长、分层组织文档的固有困难。
Because user stories and scenarios are completely void of technical jargon, they are totally comprehensible to users and customers. While well-written use cases may avoid technical jargon, readers of use cases must typically learn how to interpret the format of the use cases. Very few first-time readers of a use case have an implicit understanding of common fields on use case forms such as extensions, preconditions and guarantees. Typical IEEE 830 documents suffer from both the inclusion of technical jargon and from the inherent difficulty of comprehending a lengthy, hierarchically-organized document.
故事和场景的更易访问性鼓励用户成为软件设计的参与者。此外，随着用户学习如何在对开发人员直接有用的故事中描述他们的需求，开发人员会更积极地吸引用户。这种良性循环使参与开发或使用软件的每个人都受益。
The greater accessibility of stories and scenarios encourages users to become participants in the design of the software. Further, as users learn how to characterize their needs in stories that are directly useful to developers, developers more actively engage the users. This virtuous cycle benefits everyone involved in developing or using the software.
故事建立隐性知识
Stories Build Up Tacit Knowledge
由于强调面对面的交流，故事促进了团队中隐性知识的积累。开发人员和客户彼此之间以及彼此之间交谈的次数越多，团队内部积累的知识就越多。
Because of the emphasis placed on face-to-face communication, stories promote the accumulation of tacit knowledge across the team. The more often developers and customers talk to each other and among themselves, the more knowledge builds up within the team.
为什么不是故事？
Why Not Stories?
在了解了为什么故事是满足敏捷需求的首选方法的众多原因之后，让我们也考虑一下它们的缺点。
Having looked at a number of reasons why stories are a preferred approach to agile requirements, let’s also consider their drawbacks.
用户故事的一个问题是，在一个有很多故事的大型项目中，很难理解故事之间的关系。这个问题可以通过使用角色和将故事保持在中等到高级水平来减轻，直到团队准备好开始开发故事。用例具有固有的层次结构，有助于处理大量需求。一个单一的用例，通过它的主要成功场景和扩展，可以将许多用户故事的等效物收集到一个单一的实体中。
One problem with user stories is that, on a large project with many stories, it can be difficult to understand the relationships between stories. This problem can be lessened by using roles and by keeping stories at a moderate to high level until the team is ready to start developing the stories. Use cases have an inherent hierarchy that helps when working with a large number of requirements. A single use-case, through its main success scenario and extensions, can collect the equivalent of many user stories into a single entity.
用户故事的第二个问题是，如果您的开发过程要求可追溯性，您可能需要用额外的文档来扩充它们。幸运的是，这通常可以以非常轻量级的方式完成。例如，在一个项目中，我们将开发分包给一家更大的 ISO 9001 认证公司，我们需要证明从需求到测试的可追溯性。我们以一种非常轻松的方式实现了这一点：在每次迭代开始时，我们制作了一份文档，其中包含我们计划在迭代中完成的每个故事。随着测试的开发，测试名称被添加到文档中。在迭代期间，我们通过添加或删除移入或移出迭代的故事来使文档保持最新。我们流程中的这一添加可能每月要花费一个小时。
A second problem with user stories is that you may need to augment them with additional documentation if requirements traceability is mandated of your development process. Fortunately, this can usually be done in a very lightweight manner. For example, on one project where we were doing subcontracted development to a much larger, ISO 9001-certified company, we were required to demonstrate traceability from requirements to tests. We achieved this in a very light manner: At the start of each iteration we produced a document that contained each story we planned to do in the iteration. As tests were developed, the test names were added to the document. During the iteration we kept the document up to date by adding or removing stories that moved into or out of the iteration. This addition to our process probably cost us an hour a month.
最后，虽然故事在增强团队内的隐性知识方面非常出色，但它们可能无法很好地扩展到超大型团队。大型团队的一些沟通必须简单地写下来，否则信息不会分散到团队中的许多人中。然而，请记住，大量的人知道一点（通过书面、低带宽文档）和少数人知道很多（通过高带宽的面对面对话）之间非常真实的权衡。
Finally, while stories are fantastic at enhancing tacit knowledge within a team, they may not scale well to extremely large teams. Some communication on large teams simply must be written down or the information does not get dispersed among as many on the team. However, keep in mind the very real tradeoff between a large number of people knowing a little (through written, low-bandwidth documents) and a smaller number of people knowing a lot (through high-bandwidth face–to–face conversations).
概括
Summary
- 用户故事迫使人们转向口头交流。与其他完全依赖书面文档的需求技术不同，用户故事非常重视开发人员和用户之间的对话。
- User stories force a shift to verbal communication. Unlike other requirements techniques that rely entirely on written documents, user stories place significant value on conversations between developers and users.
- 向口头交流的转变提供了快速的反馈周期，从而导致更好的理解。
- The shift toward verbal communicate provides rapid feedback cycles, which leads to greater understanding.
- 开发人员和用户都可以理解用户故事。IEEE 830 软件需求规范往往充满了太多的技术或商业术语。
- User stories are comprehensible by both developers and users. IEEE 830 software requirements specifications tend to be filled with too much technical or business jargon.
- 用户故事的范围通常小于用例和场景，但大于 IEEE 830 声明，是规划的合适规模。规划以及编程和测试可以通过故事完成，而无需进一步聚合或分解。
- User stories, which are typically smaller in scope than use cases and scenarios but larger than IEEE 830 statements, are the right size for planning. Planning, as well as programming and testing, can be completed with stories without further aggregation or disaggregation.
- 用户故事适用于迭代开发，因为很容易从一个史诗故事开始，然后将其拆分为多个较小的用户故事。
- User stories work well with iterative development because it is easy to start with an epic story and later split it into multiple smaller user stories.
- 用户故事鼓励推迟细节。单个用户故事可能写得很快，写不同大小的故事也非常容易。不太重要的领域，或者最初不会开发的领域，可以很容易地留下作为史诗，而其他故事则写得更详细。
- User stories encourage deferring details. Individual user stories may be written very quickly, and it is also extremely easy to write stories of different sizes. Areas of less importance, or that won’t be developed initially, may easily be left as epics, while other stories are written with more detail.
- 故事鼓励机会主义的发展，在这种情况下，当机会被发现时，团队会很容易地在高细节和低细节之间转移注意力。
- Stories encourage opportunistic development, in which the team readily shifts focus between high and low levels of detail as opportunities are discovered.
- 故事提高了团队的隐性知识水平。
- Stories enhance the level of tacit knowledge on the team.
- 用户故事鼓励参与式设计，而不是经验式设计，在这种设计中，用户成为设计软件行为的积极和有价值的参与者。
- User stories encourage participatory, rather than empirical, design, in which users become active and valued participants in designing the behavior of the software.
- 虽然使用故事的原因有很多，但它们确实有一些缺点：在大型项目中，很难组织成百上千的故事；它们可能需要增加额外的文件以实现可追溯性；而且，虽然通过面对面的交流可以很好地提高隐性知识，但对话的规模不足以完全取代大型项目中的书面文件。
- While there are many reasons to use stories, they do have some drawbacks: on large projects it can be difficult to keep hundreds or thousands of stories organized; they may need to be augmented with additional documents for traceability; and, while great at improving tacit knowledge through face–to–face communication, conversations do not scale adequately to entirely replace written documents on large projects.
开发者责任
Developer Responsibilities
- 您有责任了解您选择任何技术的原因。如果项目团队决定编写用户故事，您有责任了解原因。
- You are responsible for understanding why you have chosen any technique you choose. If the project team decides to write user stories, you are responsible for knowing why.
- 您有责任了解其他需求技术的优势，或了解何时适合应用一种技术。例如，如果您正在与客户合作并且无法理解某个功能，那么讨论交互设计场景或开发用例可能会有所帮助。
- You are responsible for knowing the advantages of other requirements tecniques or for knowing when it may be appropriate to apply one. For example, if you are working with a customer and cannot come to an understanding about a feature, perhaps discussing an interaction design scenario or developing a use case may help.
客户责任
Customer Responsibilities
- 与其他需求方法相比，用户故事的最大优势之一是它们鼓励参与式设计。您有责任成为设计软件功能的积极参与者。
- One of the biggest advantages of user stories over other requirements approaches is that they encourage participatory design. You are responsible for becoming an active participant in designing what your software will do.
问题
Questions
13.1使用用户故事表达需求的四个充分理由是什么？
13.1 What are four good reasons for using user stories to express requirements?
13.2使用用户故事的两个缺点是什么？
13.2 What can be two drawbacks to using user stories?
13.3参与式设计和实证设计之间的主要区别是什么？
13.3 What is the key difference between participatory and empirical design?
13.4要求声明“所有多页报告都应编号”有什么问题？
13.4 What is wrong with the requirements statement, “All multipage reports should be numbered”?
第 14 章故事气味目录
Chapter 14. A Catalog of Story Smells
本章将介绍“难闻气味”的目录，即表明项目的用户故事应用程序存在问题的指标。将描述每种气味并提供一种或多种解决方案。
This chapter will present a catalog of “bad smells,” that is, indicators that something is amiss in a project’s application of user stories. Each smell will be described and one or more solutions provided.
故事太小
Stories Are Too Small
Symptom: A frequent need to revise estimates.
讨论：小故事通常会导致故事的估计和安排出现问题。发生这种情况是因为根据故事的实施顺序，分配给小故事的估算可能会发生巨大变化。例如，考虑以下两个小故事：
Discussion: Small stories often cause problems with the estimating and scheduling of stories. This happens because the estimate assigned to a small story can change dramatically depending on the order in which the story is implemented. For example, consider these two small stories:
- 搜索结果可以保存到 XML 文件中。
- Search results may be saved to an XML file.
- 搜索结果可以保存到 HTML 文件中。
- Search results may be saved to an HTML file.
这两个故事之间显然有很多重叠的工作。花在其中一个故事上的时间会减少花在另一个故事上的时间。出于规划目的，应将此类故事结合起来。当故事被放入一个迭代中时，故事可以被拆分；但是，除非有必要，否则这些故事应该保持组合。
There is clearly a great deal of overlapping work between these two stories. Time spent on one of the stories will reduce the time spent on the other. Stories like these should be combined for planning purposes. When the story is slotted into an iteration the story can be split; but, until it is necessary, the stories should remain combined.
相互依存的故事
Interdependent Stories
Symptom: Difficulty planning iterations because of dependencies between stories.
讨论：当两个或多个故事相互依赖时，很难将各个故事规划到迭代中。团队发现自己处于这样一种情况，即特定故事只能添加到迭代中，如果另一个故事也被添加到迭代中。但是只有在添加了第三个故事的情况下才能添加那个故事，依此类推。这是由于故事太小或分割不当造成的。
Discussion: When two or more stories are dependent upon one another, it becomes difficult to plan the individual stories into iterations. The team finds itself in a situation where a particular story may only be added to an iteration if another story is also added to the iteration. But that story may only be added if a third story is also added, and so on. This is caused when stories are either too small or have been inappropriately split.
如果您怀疑故事太小，简单的解决方案是将相互依赖的故事简单地合并为一个。相反，如果出于所有其他目的，这些故事的大小似乎都合适，那么请查看相互依赖的故事是如何分离的。第 7 章“好故事指南”提出了将故事拆分成完整的“小菜一碟”的建议，包括应用程序所有层的功能。
If you suspect that stories are too small, the easy solution is to simply combine the interdependent stories into one. If, instead, the stories appear for all other purposes to be appropriately sized, then look at how the interdependent stories have been separated. Chapter 7, “Guidelines for Good Stories,” offered the suggestion that stories be split so as to be a full “slice of cake,” including functionality from all layers of the application.
镀金
Goldplating
症状：开发人员正在添加未计划用于迭代的功能，或者正在自由地解释故事并超出实现故事所需的范围。
Symptom: Developers are adding features that were not planned for the iteration, or are interpreting stories liberally and going beyond what is necessary to implement a story.
讨论： 镀金是指开发人员添加不必要的功能。一些开发人员倾向于添加增强功能或超越满足客户规定需求所需的内容。发生这种情况可能有几个原因。首先，一些开发人员喜欢让客户“惊叹”，而随着客户更多地参与敏捷流程，这就更难做到了。如果客户每天都参与其中，就很难给她一个惊喜，也很难得到一些开发人员喜欢的“哇”。
Discussion: Goldplating refers to the addition of unnecessary features by the developers. Some developers have a tendency to add enhancements or to go beyond what is needed to satisfy a customer’s stated needs. This can happen for a couple of reasons. First, some developers like “wowing” the customer and that is harder to do with the greater customer involvement in agile processes. If the customer is involved day–to–day it is hard to give her a pleasant surprise and get the “wow” some developers enjoy.
其次，在处理敏捷的、故事驱动的短迭代项目时，开发人员通常会感受到始终保持生产的巨大压力。镀金让他们有短暂的机会摆脱这种压力。毕竟，如果功能不能及时完成，甚至没有人知道它已经启动。
Second, when working on agile, story-driven projects with short iterations, developers typically feel a great deal of pressure to always be producing. Goldplating allows them a brief chance to escape this pressure. After all, if the feature can’t be finished in time, no one will even know it had been started.
最后，开发人员喜欢在项目上留下自己的印记，添加一些宠物功能是他们实现这一目标的一种方式。
Finally, developers enjoy putting their own mark on a project, and adding a few pet features is one way for them to do this.
镀金的例子
在我参与的一个项目中，我们有一个故事，将一个非常拥挤的屏幕重写为一个选项卡式对话框，以提高可用性。开发人员完成此更改后，他增强了此应用程序中的低级选项卡对话框代码，以便可以将选项卡从其当前位置撕下并在屏幕上移动。这不是客户要求的。开发人员需要专注于客户优先考虑的故事。如果开发人员对新故事有好主意，她应该将其建议给客户，以便可能包含在下一次迭代中。
On one project I was on we had a story to take a very crowded screen and rewrite it as a tabbed dialog to improve usability. After the developer finished this change, he enhanced the low-level tab dialog code in this application so that a tab could be torn from its current location and moved about the screen. This was not something the customer asked for. Developers need to stay focused on the stories prioritized by the customer. If a developer has a good idea for a new story, she should suggest it to the customer for possible inclusion in the next iteration.
如果一个项目正在经历开发人员的重大镀金，可以通过提高每个人正在处理的任务的可见性来防止这种情况发生。例如，举行简短的每日会议，让每个人都说出他或她正在做什么。通过更好地了解每个开发人员在团队中的工作，团队将自我监督以防止镀金。
If a project is experiencing significant goldplating by developers, it can be prevented by increasing the visibility of the tasks that everyone is working on. For example, hold brief daily meetings where everyone says what he or she is working on. With greater visibility into what each developer is working on the team will self-police against gold-plating.
类似地，在迭代结束审查会议上向客户和其他利益相关者详细演示所有新功能将有助于识别迭代期间发生的镀金。在该迭代期间纠正它为时已晚，但团队会在未来的迭代中更加了解它。
Similarly, end–of–iteration review meetings where all of the new functionality is demonstrated in detail for the customer and other stakeholders will help identify goldplating that occurred during the iteration. It will be too late to correct it during that iteration but the team will be more aware of it for future iterations.
最后，如果项目有 QA 组织，他们也可以帮助识别镀金，特别是如果他们参与了程序员和客户之间的对话。
Finally, if the project has a QA organization they can also help identify goldplating, especially if they were involved in the conversations between the programmer and the customer.
太多细节
Too Many Details
症状：在实施故事之前花太多时间收集细节。或者，更多的时间花在写故事上而不是谈论故事上。
Symptom: Too much time is being spent gathering details well in advance of a story being implemented. Or, more time is spent writing about stories than talking about them.
讨论：在记事卡上写故事的好处之一是可用于写故事的空间非常有限。很难在一张小卡片上塞满很多细节。在故事中包含太多细节表明对文档的重视程度过高，并且比对话更喜欢它。
Discussion: One of the benefits to writing stories on notecards is that the space available for writing the story is quite limited. It is hard to cram lots of detail onto a small card. Including too many details in a story is indicative of placing too much value on documentation and favoring it over conversation.
Tom Poppendieck (2003)观察到“如果空间不足，请使用较小的卡片。” 这是一个好主意，因为它迫使故事作者非常有意识地在故事中包含更少的细节。
Tom Poppendieck (2003) has made the observation that “If you run out of room, use a smaller card.” This is a great idea because it forces story writers to very consciously include fewer details in the stories.
过早包含用户界面细节
Including User Interface Detail Too Soon
症状：在项目（尤其是开发新产品的项目）早期编写的故事包含有关用户界面的详细信息。
Symptom: Stories written early in a project (especially a project to develop a new product) that include detail about the user interface.
讨论：在项目的某个时刻，团队肯定会使用关于用户界面的非常直接的假设（甚至直接知识）来编写用户故事。例如，“求职者可以从职位描述页面查看有关招聘公司的信息。” 但是，您应该尽可能避免使用这种详细程度来编写故事。
Discussion: At some point on a project the team will definitely write user stories with very direct assumptions (or even direct knowledge) about the user interface. For example, “A Job Seeker can view information about the hiring company from the Job Description page.” However, for as long as possible you should avoid writing stories with this level of detail.
在项目的早期，您不知道会有一个“职位描述页面”，因此请避免通过将故事与项目相关联来限制项目。代替上面的故事，写一个这样的故事：“当查看有关工作的详细信息时，求职者可能会查看有关招聘公司的信息。”
Early in the project you do not know that there will be a “Job Description page” so avoid constraining the project by associating stories with it. Instead of the story above, write one such as “When viewing details about a job, a Job Seeker may view information about the hiring company.”
想得太远
Thinking Too Far Ahead
症状：这种气味的迹象可能是故事很难放在笔记卡上，有兴趣使用软件系统而不是不受团队规模或位置驱动的笔记卡，有人提出了一个故事模板来捕获所有故事所必需的细节，或者可能提出更精确的估计（例如，小时而不是天）的建议。
Symptom: Indicators of this smell may be that stories are hard to fit on note cards, there is interest in using a software system instead of note cards that isn’t driven by team size or location, someone proposes a story template to capture all of the details necessary for a story, or perhaps that a suggestion is made to give estimates in finer precision (for example, hours instead of days).
讨论：这种气味在习惯于大量前期“需求工程”工作的团队中尤为常见。对于克服这种气味的团队来说，他们可能需要一门关于故事优势的复习课程。使用故事的基础是认识到对于大多数问题来说，不可能提前确定所有需求。好的软件是通过反复迭代出现的，在迭代中，越来越多的细节被添加到软件中。故事很适合这种方法，因为在故事的后续版本中可以轻松表达细节。团队可能需要提醒自己，是什么导致他们采用故事的先前开发过程。
Discussion: This smell is particularly common among teams accustomed to large upfront “requirements engineering” efforts. For a team to overcome this smell they may need a refresher course on the strengths of stories. Fundamental to the use of stories is the recognition that for most problems it is impossible to identify all requirements in advance. Good software emerges through repeated iterations in which increasing amounts of detail are added to the software. Stories fit well with this approach because of the ease with which detail can be expressed in later versions of a story. The team may need to remind itself what it was about their prior development process that led them to adopt stories.
拆分太多故事
Splitting Too Many Stories
症状：在迭代计划期间频繁拆分故事，以便在迭代中适合适当的工作量。
Symptom: Frequently splitting stories during iteration planning so that the right amount of work fits in the iteration.
讨论：当开发人员和客户选择他们将进入迭代的故事时，他们有时需要将故事拆分为两个或更多组成故事。通常，出于以下两个原因之一，在计划期间需要拆分故事：
Discussion: When the developers and customer select the stories they will move into an iteration, they will sometimes need to split a story into two or more constituent stories. Typically a story needs to be split during planning for one of two reasons:
1. 故事太大，不适合迭代。
1. The story is too large to fit into the iteration.
2.故事包含高低子故事，客户只希望在即将到来的迭代中完成高优先级的子故事。
2. The story contains both high and low sub-stories, and the customer only wants the high priority sub-stories done during the coming iteration.
这些情况都不能代表问题。许多项目和团队都会遇到拆分故事以适应的情况冲刺的持续时间并符合团队观察到的速度。然而，当团队发现自己经常拆分故事时，情况就开始变味了。
Neither of these cases is representative of a problem. Many projects and teams will have occasions when it will be useful to split a story to accommodate the duration of a sprint and fit with the team’s observed velocity. However, the situation begins to smell when the team finds itself splitting stories frequently.
如果故事被拆分的频率超出了合理的范围，那么请考虑遍历剩余的故事并寻找应该拆分的故事。
If stories are being split more often than feels reasonable, then consider taking a pass through the remaining stories and looking for stories that should be split.
客户难以确定优先级
Customer Has Trouble Prioritizing
症状：选择故事并确定故事的优先级通常很困难；但有时很难确定故事的优先级，以至于可以将其视为一种气味。
Symptom: Choosing among and prioritizing stories is often difficult; but sometimes prioritizing the stories is so difficult that it can be considered a smell.
讨论：如果客户在确定故事的优先级时遇到困难，首先要考虑的是故事的大小。如果故事太大，就很难确定它们的优先级。假设，在极端情况下，BigMoneyJobs 网站仅包含以下三个故事：
Discussion: If a customer is having trouble prioritizing stories, the first thing to consider is the size of the stories. If stories are too large, they can be difficult to prioritize. Suppose, at the extreme, the BigMoneyJobs website included only the following three stories:
- 求职者可以搜索工作。
- A Job Seeker can search for jobs.
- 公司可以发布职位空缺。
- A Company can post a job opening.
- 招聘人员可以搜索候选人。
- A Recruiter can search for candidates.
可怜那些只能在这些故事中优先考虑的可怜的顾客！她的反应可能是说，“但我不能吃一点这个和一点那个吗？” 在这种情况下，摆脱当前故事并用较小的故事替换它们，以便她可以选择她想要的每个故事的片段。
Pity the poor customer who has to prioritize only among these stories! Her reaction is probably to say, “But can’t I have a little of this and some of that?” In this case, get rid of the current stories and replace them with smaller ones so that she can select the pieces of each that she wants.
此外，如果故事不是为了表达商业价值而编写的，则可能很难确定故事的优先级。例如，假设向客户展示了这些故事：
Also, it may be difficult to prioritize stories if they have not been written to express business value. For example, suppose the customer is presented with these stories:
- 用户通过连接池连接到数据库。
- A user connects to the database via a connection pool.
- 用户可以在日志文件中查看详细的错误信息。
- A user can view detailed error information in a log file.
客户很难确定此类故事的优先级，因为每个故事的商业价值都不明确。应该重写故事，以便客户清楚每个故事的价值。每个故事的重写方式取决于客户的技术知识，这就是为什么最好的建议是让客户自己编写故事。例如，考虑前面故事的这些重写版本：
Stories like these can be very difficult for the customer to prioritize because the business value of each is not clear. The stories should be rewritten so that the value of each is clear to the customer. How each is rewritten will vary depending on the customer’s technical knowledge, which is why the best recommendation is to have the customer write the stories herself. For example, consider these rewritten versions of the preceding stories:
- 用户可以在连接到数据库时启动应用程序而不会出现明显的延迟。
- A user can start the application without a noticeable lag while connecting to the database.
- 每当发生错误时，都会向用户提供足够的信息以了解如何更正错误。
- Whenever an error occurs, users are given enough information to know how to correct the error.
客户不会撰写故事并确定故事的优先级
Customer Won’t Write and Prioritize the Stories
Symptom: The customer on a project will not accept responsibility for writing or prioritizing the stories.
讨论：在一个充满责备的组织中，总有一些人知道他们最好的决定是避免所有责任。如果你不对某件事负责，那么当它失败时你就不会受到责备，但通常有一种方法可以宣称至少取得了一些成功。在这种文化中的个人将不想做艰难的决定，比如确定发布和退出发布的功能的优先级。他们会求助于诸如“你不能在截止日期前完成所有事情不是我的问题，想办法做到这一点”之类的陈述。
Discussion: In a blame-filled organization there are always some individuals who have learned that their best decision is to avoid all responsibility. If you’re not responsible for something you can’t be blamed for it when it fails, yet there’s usually a way to lay claim to at least some of the success. Individuals in this type of culture will want nothing to do with hard decisions like prioritizing features into and out of releases. They’ll fall back on statements such as “It’s not my problem that you can’t complete everything by the deadline, figure out a way to do it.”
在这些情况下，我发现的最佳解决方案是找到一种让客户摆脱困境的方法。我找到了一种让她表达意见的非威胁性方式。根据个人情况，这可能必须是私人谈话。如果我与多个客户一起工作，我会告诉他们每个人我正在收集其他人的意见，但我是对最终决定负责的人，尤其是当他们被证明是错误的时候。
The best solution I’ve found in these situations is to find a way to let the customer off the hook. I find a non-threatening way for her to express her opinions. Depending on the individual, this may have to be a private conversation. If I’m working with multiple customers, I tell them each that I’m collecting input from others but that I’m the one who will be responsible for the final decisions, especially if they turn out to be wrong.
概括
Summary
在本章中，我们了解了以下气味：
In this chapter we learned about the following smells:
- 太小的故事
- stories that are too small
- 相互依存的故事
- interdependent stories
- 镀金
- goldplating
- 在故事中添加太多细节
- adding too many details to stories
- 过早包括用户界面细节
- including user interface details too soon
- 想得太远
- thinking too far ahead
- 拆分太多的故事
- splitting too many stories
- 优先考虑故事时遇到麻烦
- trouble when prioritizing stories
- 客户不会写故事并确定故事的优先级
- customer won’t write and prioritize stories
开发者责任
Developer Responsibilities
- 您与客户共同负责了解这些气味以及您可能检测到的任何其他气味，然后努力纠正任何影响您项目的气味。
- You share a responsibility with the customer to be aware of these smells—as well as any others you may detect—and then to work to correct any that affect your project.
客户责任
Customer Responsibilities
- 您与开发人员共同负责了解这些气味——以及您可能检测到的任何其他气味——然后努力纠正任何影响您的项目的气味。
- You share a responsibility with the developers to be aware of these smells—as well as any others you may detect—and then to work to correct any that affect your project.
问题
Questions
14.1如果团队一直发现难以计划下一次迭代，您应该怎么办？
14.1 What should you do if the team is consistently finding it difficult to plan the next iteration?
14.2如果团队一直没有足够的空间来写故事卡，他们应该怎么办？
14.2 What should the team do if they are consistently running out of room to write on the story cards?
14.3什么会导致客户难以确定故事的优先级？
14.3 What could cause the customer to have a difficult time prioritizing stories?
14.4你怎么知道你是否拆分了太多的故事？
14.4 How do you know if you are splitting too many stories?
第 15 章在 Scrum 中使用故事
Chapter 15. Using Stories with Scrum
用户故事起源于极限编程的一部分。自然地，故事与极限编程的其他实践完美契合。然而，故事也可以作为其他过程的需求方法。
User stories originated as part of Extreme Programming. Naturally, stories fit perfectly with the other practices of Extreme Programming. However, stories also work well as the requirements approach for other processes.
在本章中，我们将了解另一个敏捷过程 Scrum，并将了解故事如何作为 Scrum 的重要组成部分进行整合。[1]作为 Scrum 词典一部分的术语在首次使用时将以斜体显示。
In this chapter we’ll look at Scrum, another agile process, and will see how stories can be integrated as an important part of Scrum.[1] Terms that are part of the Scrum lexicon will be italicized when first used.
Scrum 是迭代和增量的
Scrum Is Iterative and Incremental
与 XP 一样，Scrum 既是迭代过程又是增量过程。由于这些词在没有定义的情况下如此频繁地使用，我们将对它们进行定义。
Like XP, Scrum is both an iterative and an incremental process. Since these words are used so frequently without definition, we’ll define them.
迭代过程是通过连续改进取得进展的过程。开发团队在了解系统在某些（可能是许多）领域不完整或薄弱的情况下进行了第一次切割。然后他们反复改进这些区域，直到产品令人满意为止。每次迭代都会通过添加更多细节来改进软件。例如，在第一次迭代中，搜索屏幕可能被编码为仅支持最简单的搜索类型。第二次迭代可能会添加额外的搜索条件。最后，第三次迭代可能会添加错误处理。
An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. They then iteratively refine those areas until the product is satisfactory. With each iteration the software is improved through the addition of greater detail. For example, in a first iteration a search screen might be coded to support only the simplest type of search. The second iteration might add additional search criteria. Finally, a third iteration may add error handling.
一个很好的类比是雕刻。首先，雕刻家选择合适大小的石头。接下来，雕刻家从石头上雕刻出大致的形状。至此，或许可以分辨出头部和躯干，并看出完成的作品将是人体而非鸟类。接下来，雕塑家通过添加细节来完善她的作品。然而，在整个作品完成之前，雕塑家不太可能将任何一个区域视为完整。
A good analogy is sculpting. First the sculptor selects a stone of the appropriate size. Next the sculptor carves the general shape from the stone. At this point one can perhaps distinguish the head and torso, and discern that the finished work will be of a human body rather than a bird. Next, the sculptor refines her work by adding detail. However, the sculptor is unlikely to look on any one area as complete until the entire work is complete.
增量过程是一种软件构建和交付的过程。每个部分或增量代表一个完整的功能子集。增量可大可小，范围可能从小端的系统登录屏幕到高度灵活的数据管理屏幕集。每个增量都经过完整的编码和测试，并且普遍期望迭代的工作不需要重新访问。
An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end to a highly flexible set of data management screens. Each increment is fully coded and tested, and the common expectation is that the work of an iteration will not need to be revisited.
一个渐进的雕塑家会选择她作品的一部分并完全专注于它直到完成。她可以选择小的增量（首先是鼻子，然后是眼睛，然后是嘴巴，等等）或大的增量（头、躯干、腿，然后是手臂）。但是，无论增量大小如何，增量雕刻师都会尝试尽可能完整地完成该增量的工作。
An incremental sculptor would pick one part of her work and focus entirely on it until it’s finished. She may select small increments (first the nose, then the eyes, then the mouth, and so on) or large increments (head, torso, legs and then arms). However, regardless of the increment size, the incremental sculptor would attempt to finish the work of that increment as completely as possible.
Scrum 和 XP 都是增量和迭代的。它们是迭代的，因为它们计划在后续迭代中改进一次迭代的工作。它们是增量的，因为完成的工作是在整个项目中交付的。
Scrum and XP are both incremental and iterative. They are iterative in that they plan for the work of one iteration to be improved upon in subsequent iterations. They are incremental because completed work is delivered throughout the project.
Scrum 的基础知识
The Basics of Scrum
Scrum 项目通过一系列称为冲刺的 30 天迭代来取得进展。在每个冲刺开始时，团队确定在该冲刺期间可以完成的工作量。工作是从称为产品待办事项列表的优先列表中选择的。团队认为可以在冲刺期间完成的工作被移到称为冲刺积压的列表中。举行一次简短的每日会议，即每日站会，让团队检查其进度并根据需要进行调整。从图形上看，Scrum如图 15.1所示，该图改编自 Ken Schwaber 的网站www.controlchaos.com。
Scrum projects progress through a series of thirty-day iterations called sprints. At the start of each sprint the team determines the amount of work it can accomplish during that sprint. Work is selected from a prioritized list called the product backlog. The work the team believes it can complete during the sprint is moved onto a list called the sprint backlog. A brief daily meeting, the daily scrum, is held to allow the team to inspect its progress and to adapt as necessary. Graphically, Scrum is as shown in Figure 15.1, which is adapted from Ken Schwaber’s website at www.controlchaos.com.
图 15.1。 Scrum 过程的图形表示。
Figure 15.1. Graphical representation of the Scrum process.
Scrum 团队
The Scrum Team
一个 Scrum 团队通常由四到七名开发人员组成。虽然 Scrum 团队可能包括专业开发人员（例如测试人员和数据库管理员），但 Scrum 团队共享一种“我们都在一起”的态度。如果需要进行测试并且没有可用的专用测试仪，则由其他人进行测试。所有作品都是集体所有。Scrum 团队是自组织的。也就是说，没有管理指令说明 Mary 编码和 Bill 测试。正因为如此，程序员、架构师和测试人员通常不用于 Scrum 团队。团队如何完成工作的一切都由团队决定。
A Scrum team typically consists of four to seven developers. While a Scrum team may involve specialist developers—testers and database administrators, for example—a Scrum team shares a “we’re all in this together” attitude. If there is testing to be done and there is no dedicated tester available, then someone else does the testing. All work is owned collectively. Scrum teams are self-organizing. That is, there is no management directive stating that Mary codes and Bill tests. Because of this, role names such as programmer, architect and tester are generally not used on Scrum teams. Everything about how a team accomplishes its work is left up to the team.
这个核心团队由两个关键人员补充：产品负责人和ScrumMaster。Scrum 产品负责人本质上是极限编程的客户。产品负责人主要负责将项目放入所需功能的产品积压列表中并确定其优先级。ScrumMaster 类似于项目经理，只是其角色更多的是领导而不是管理。因为 Scrum 团队是自组织的，并且在如何完成冲刺工作方面有很大的回旋余地，所以项目的 ScrumMaster 为团队服务而不是指导团队。ScrumMaster 通常通过消除阻碍进步的障碍并帮助团队遵循 Scrum 的一些简单规则来为她的团队服务。
This core team is supplemented by two key people: the product owner and the ScrumMaster. A Scrum product owner is essentially the customer of Extreme Programming. The product owner is largely responsible for placing items onto and prioritizing the product backlog list of needed functionality. The ScrumMaster is similar to a project manager except that the role is much more one of leadership than of managing. Because Scrum teams are self-organizing and given great leeway in how they complete the work of a sprint, the project’s ScrumMaster serves the team rather than directs it. A ScrumMaster typically serves her team by removing obstacles to progress and by helping the team follow the few simple rules of Scrum.
产品积压
The Product Backlog
产品待办事项列表是产品所需的所有功能的主列表。当一个项目启动时，并没有全面的努力来写下所有可预见的特征。通常，产品负责人和团队会写下所有明显的东西，这对于第一次冲刺来说几乎总是绰绰有余。随着对产品及其客户的更多了解，产品待办事项列表可以增长和变化。
The product backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive effort to write down all foreseeable features. Typically, the product owner and team write down everything obvious, which is almost always more than enough for a first sprint. The product backlog is then allowed to grow and change as more is learned about the product and its customers.
表 15.1显示了来自真实项目的产品积压示例。从该表中可以看出，待办事项可以是技术任务（“重构登录类以引发异常”）或更以用户为中心（“允许在设置屏幕上撤消”）。
An example product backlog from a real project appears as shown in Table 15.1. As you can see from this table, backlog items can be technical tasks (“Refactor the Login class to throw an exception”) or more user-centric (“Allow undo on the setup screen”).
产品负责人将产品待办事项按优先顺序排序。更好的是，产品所有者可以（实际上是鼓励）随着优先级逐月变化而对产品积压项目进行洗牌。
The product owner sorts the product backlog into priority order. Even better, the product owner is allowed (actually encouraged) to shuffle the product backlog items as priorities change from month to month.
表 15.1。 样本产品积压清单。
Table 15.1. A sample product backlog list.
Sprint 计划会议
The Sprint Planning Meeting
冲刺计划会议在每个冲刺开始时举行。会议通常持续一整天，产品负责人、ScrumMaster 和整个开发团队都会参加。参加会议的可能还有任何感兴趣且合适的管理人员或客户代表。
A sprint planning meeting is held at the start of each sprint. The meeting usually lasts up to a full day and is attended by the product owner, the ScrumMaster and the entire team of developers. Also attending may be any interested and appropriate management or customer representatives.
在冲刺计划会议的前半部分，产品负责人向团队描述了最高优先级的剩余功能。团队提出了足够多的问题，以便在会议的后半段他们可以确定将哪些项目从产品待办事项列表移至冲刺待办事项列表。
During the first half of the sprint planning meeting, the product owner describes the highest priority remaining features to the team. The team asks enough questions that during the second half of the meeting they can determine which items they will move from the product backlog to the sprint backlog.
产品负责人不必描述产品待办事项列表中跟踪的每个项目。根据积压的大小和团队的速度，仅描述高优先级的项目可能就足够了，将低优先级项目的讨论留到下一次冲刺计划会议。通常，当 Scrum 团队开始深入处理待办事项列表时，他们会提供指导，而不是他们知道在即将到来的 sprint 中可以完成的事情。
The product owner does not have to describe every item being tracked on the product backlog. Depending on the size of the backlog and the velocity of the team it may be sufficient to describe only the high priority items, saving the discussion of lower priority items for the next sprint planning meeting. Typically, the Scrum team will provide guidance when they start to get further into the backlog list than they know can be done in the upcoming sprint.
团队和产品负责人共同定义一个冲刺目标，这是对团队计划在该冲刺期间实现的目标的简短描述。在一个在冲刺结束时举行的冲刺回顾会议，团队将根据冲刺目标评估他们的成功，而不是针对从产品待办列表中选择的每个特定项目。
Collectively the team and the product owner define a sprint goal, which is a short description of what the team plans to achieve during that sprint. In a sprint review meeting held at the end of the sprint, the team will assess their success against the sprint goal, rather than against each specific item selected from the product backlog.
在 sprint 计划会议的后半部分，团队单独开会讨论他们听到的内容，并决定在接下来的 sprint 中他们可以承诺多少。从概念上讲，团队从优先级产品待办列表的顶部开始，并在他们认为可以完成的最低优先级任务之后画一条线。在实践中，经常会看到一个团队选择，例如，前五个项目，然后从列表中较低的两个项目中选择与前五个相关的项目。在某些情况下，将与产品负责人进行协商，但始终由团队决定他们可以承诺完成多少。
During the second half of the sprint planning meeting, the team meets separately to discuss what they heard and decide how much they can commit to during the coming sprint. Conceptually, the team starts at the top of the prioritized product backlog list and draws a line after the lowest of the high priority tasks they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five. In some cases there will be negotiation with the product owner, but it will always be up to the team to determine how much they can commit to completing.
Scrum 的主要规则
冲刺计划会议在每个冲刺开始时举行。
A sprint planning meeting is held at the start of each sprint.
每个冲刺都必须交付有效且经过全面测试的代码，以向最终用户或客户展示有价值的东西。
Each sprint must deliver working and fully tested code that demonstrates something of value to end-users or the customer.
产品负责人对产品待办事项进行优先级排序。
The product owner prioritizes the product backlog.
团队共同选择带入冲刺的工作量。
The team collectively selects the amount of work brought into the sprint.
一旦 sprint 开始，只有团队可以添加到 sprint backlog。
Once a sprint begins, only the team may add to the sprint backlog.
产品待办事项列表可以随时添加或重新排列优先级。
The product backlog may be added to or reprioritized at any time.
每天举行一次简短的 Scrum 会议。每个项目参与者回答：你昨天做了什么？你今天会做什么？你的路上有什么障碍？
A short scrum meeting is held every day. Each project participant answers: What did you do yesterday? What will you do today? What obstacles are in your way?
只有 sprint 的积极参与者（不感兴趣的观察员或被移除的利益相关者）可以在每日 scrum 会议上发言。
Only active participants in the sprint (not interested observers or removed stakeholders) may speak during the daily scrum meeting.
冲刺的结果在冲刺结束时的冲刺审查会议上展示。
The result of a sprint is demonstrated at a sprint review meeting at the end of the sprint.
在 sprint 评审期间演示工作软件。不允许放映幻灯片。
Working software is demonstrated during the sprint review. No slideshows are allowed.
准备冲刺评审的时间不得超过两个小时。
No more than two hours may be spent preparing for the sprint review.
冲刺开始后，只有团队可以向冲刺添加工作。CEO 不能接近团队并要求产品所有者遗漏的东西。销售人员不能为特殊客户要求更多功能。并且产品所有者不能改变主意并要求额外的功能。唯一可以在冲刺中添加工作的情况是团队发现自己提前完成了计划。那时团队可以请产品负责人帮助确定一两个额外的项目。
Once the sprint starts, only the team may add work to the sprint. The CEO cannot approach the team and ask for something the product owner left out. A salesperson cannot ask for one more feature for a special customer. And the product owner cannot change her mind and ask for additional features. The only time work may be added to a sprint is if the team finds itself ahead of schedule. At that time the team can ask the product owner to help identify an additional item or two.
作为完成为冲刺选择的工作的承诺的交换，团队从组织那里得到承诺，在冲刺期间不会改变冲刺的内容。如果发生了非常重要的事情，以至于组织觉得需要更改 sprint，那么当前的 sprint 就会中止，并通过另一个 sprint 计划会议开始新的 sprint。
In exchange for their commitment to complete the work selected for the sprint, the team receives a commitment from the organization that it will not change the contents of sprint for the duration of the sprint. If something so significant happens that the organization feels it needs to change the sprint, then the current sprint is aborted and a new sprint is started by beginning with another sprint planning meeting.
当团队从产品待办列表中选择项目时，他们将它们扩展到更基于任务的冲刺待办列表中。产品待办事项列表中的每一项都可以扩展为冲刺待办事项列表中的一项或多项，从而使团队能够更有效地分担工作。
As the team selects items from the product backlog, they expand them into the more task-based sprint backlog. Each item on the product backlog may expand into one or more items on the sprint backlog, allowing the team to more effectively share the work.
Sprint 评审会议
The Sprint Review Meeting
每个冲刺都需要交付潜在的可交付产品增量。这意味着在每个月的冲刺结束时，团队都会生成经过编码、测试和可用的软件。该软件必须是潜在可交付的，这意味着如果包含足够的新功能以证明交付或部署新版本的开销是合理的，则组织可以选择将软件交付给客户（或在内部使用）。例如，商业软件分销商可能不会选择每月发布一个新版本，因为升级可能会给他们的客户带来麻烦。然而，对于 Scrum，开发人员需要每月制作一个可能可交付的版本。
Each sprint is required to deliver a potentially shippable product increment. This means that at the end of each month-long sprint the team has produced a coded, tested and usable piece of software. The software must be potentially shippable, meaning that the organization could choose to ship the software to customers (or use it internally) if enough new functionality is included to justify the overhead of shipping or deploying the new version. A commercial software distributor, for example, would probably not choose to ship a new version every month because of the upgrade hassles that could cause their customers. However, with Scrum the developers are required to produce a potentially shippable version each month.
在每个冲刺结束时，召开冲刺回顾会议。在这次会议期间，团队展示了他们在冲刺期间取得的成就。通常，这采用新功能演示的形式。
At the end of each sprint, a sprint review meeting is held. During this meeting the team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.
sprint 审查会议有意保持非常非正式，通常规则禁止使用 PowerPoint 幻灯片，并且会议准备时间不得超过两个小时。sprint 评审会议不应该让团队分心或走弯路；相反，它应该是冲刺的自然结果。
The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.
整个团队以及产品负责人和 ScrumMaster 都参与了冲刺评审会议。对项目感兴趣的其他人（例如管理人员、客户或其他项目的工程师）如果愿意，可以参加冲刺评审。
The entire team as well as the product owner and ScrumMaster participate in the sprint review meeting. Others who are interested in the project (such as management, customers or engineers from other projects) may attend the sprint review if they desire.
在 sprint 评审会议期间，根据先前在 sprint 计划会议期间确定的 sprint 目标评估项目。理想情况下，团队已经完成了冲刺计划的每个项目，但更重要的是他们实现了冲刺的总体目标。
During the sprint review meeting the project is assessed against the sprint goal that was previously determined during the sprint planning meeting. Ideally, the team has completed each item planned for the sprint but it is more important that they achieve the overall goal of the sprint.
每日 Scrum 会议
The Daily Scrum Meeting
Scrum 可能是第一个包含简短每日会议的记录流程 ( Beedle 1999 )，在 Scrum 中称为“每日站会”。然而，这个想法已经迅速传播到许多其他敏捷流程，例如 XP 和功能驱动开发。只要有可能，我们都希望选择耗时最少、干扰最少的方法来收集和共享项目信息。出于许多目的，每日例会恰好实现了该目标。
Scrum is probably the first documented process to include a short daily meeting (Beedle 1999), which in Scrum is called “the daily scrum.” The idea, however, has quickly spread to many of the other agile processes such as XP and Feature-Driven Development. Whenever possible we want to choose the least time-consuming and the least-intrusive method of gathering and sharing project information. For many purposes, the daily scrum achieves exactly that goal.
每日 scrum 通常每天尽早举行，但要在整个团队都上班后举行。这通常是 9:00 或 9:30。团队中的每个人都必须参加，包括程序员、测试人员、产品负责人和 ScrumMaster。会议时间很短：通常不超过 15 分钟，绝不会超过 30 分钟。为了缩短会议时间，一些团队要求参与者站立。
The daily scrum is typically held as early as possible each day but after the entire team has arrived for work. This is typically 9:00 or 9:30. Everyone on the team is required to attend, including programmers, testers, the product owner and the ScrumMaster. The meeting is kept short: usually 15 minutes or less and never longer than 30. To keep the meeting short, some teams require participants to stand.
在每日 Scrum 中，每个团队成员回答以下三个问题：
During the daily scrum each team member answers the following three questions:
1.你昨天做了什么？
1. What did you do yesterday?
2、你今天要做什么？
2. What will you do today?
3.你的路上有什么障碍？
3. What obstacles are in in your way?
重要的是，每日站会不会被 ScrumMaster 当作盘问。会议的目标之一是让每个开发人员在他或她的同行面前做出承诺。承诺不是针对经理或公司，而是针对彼此。
It is important that the daily scrum does not come across as a grilling by the ScrumMaster. One of the goals of the meeting is to have each developer make commitments in front of his or her peers. Commitments are not made to the manager or the company but to each other.
每日 Scrum 应尽可能紧贴上述三个问题，不应转移到系统的设计部分或解决提出的问题上。这些项目在会议期间被记录下来，但随后得到解决。可以确定将开会解决问题的团队子集，但不要在每日站会期间解决问题。例如，假设有人问我们是否应该开始使用我们供应商的应用程序服务器最近发布的 5.0 版。在这种情况下，我们同意在每日 Scrum 之后立即召开另一次会议：
The daily scrum should stick as closely as possible to the three questions above, and should not move off into designing parts of the system or resolving issues that were raised. Such items are noted during the meeting but are resolved afterwards. It’s OK to identify a subset of the team that will meet to resolve an issue, but do not resolve issues during the daily scrum. For example, suppose someone asks whether we should start using the recently released version 5.0 of our vendor’s application server. In that case, we agree that right after the daily scrum another meeting will occur between:
- 技术架构师，他可以评估使用新应用服务器的技术影响
- the technical architect, who can assess the technical impact on using the new application server
- 产品负责人，来自市场营销部门，最有能力决定我们的客户是部署旧的还是新的应用程序服务器
- the product owner, who comes from the Marketing department and will be in the best position to decide if our customers will deploy the old or new application server
- 测试团队的代表，可以评估对她的团队的影响
- a representative from the test team who can assess the impact on her group
ScrumMaster 作为主持人在场，确保会议集中在这三个问题上，并以轻快的速度进行。产品负责人在场，因为她理想情况下会像其他人一样有工作要报告（“我完成了‘将书添加到购物车’故事的测试，今天我将做一些市场调查，了解我们应该使用哪些卡片接受。我应该能够在一天结束前完成它。”）。
The ScrumMaster is on hand as a facilitator and to make sure the meeting stays focused on the three questions and moves along at a brisk pace. The product owner is present because she will ideally have work to report on just like anyone else (“I finished writing tests for the ‘Add book to shopping cart’ story and today I’m going to do some market research on which cards we should accept. I should be able to finish that by the end of the day.”).
召开每日会议的一个好处是，它们可以作为高级经理或对项目状态感兴趣的任何其他人的随机检查点。通过始终如一地在一天的同一时间开会并发出一般性的“只要您有兴趣就加入我们”的邀请，团队或许能够摆脱更繁重的会议，例如每月的项目审查。然而，如果非团队成员被邀请参加每日站会，一定要制定一个规则，只有直接参与项目的人才能在会议期间提问。所以，大boss可以出席，听她的心声。但是，她不能通过提问来改变会议的方向。
One benefit to holding daily meetings is that they can serve as random checkpoints for senior managers or anyone else interested in the state of the project. By consistently meeting at the same time of day and extending a general “join us whenever you’re interested” invitation, the team may be able to get out of more onerous meetings such as monthly project reviews. However, if non-team members are invited to the daily scrums, be sure to establish a rule that only people directly on the project can ask questions during the meeting. So, the Big Boss can attend and listen to her heart’s content. She cannot, however, redirect the meeting by asking questions.
每日 scrum 为团队中的每个人提供了项目进展情况的每日快速快照。这是团队重新考虑当前任务的最佳时机。例如，假设 Randy 报告说他正在处理的故事花费的时间比他预期的要长得多，而 Andrew 报告说他大大提前了进度。在这种情况下，安德鲁可能适合与兰迪一起度过一天并完成兰迪的任务，或者安德鲁直接承担兰迪的某些任务的责任。
The daily scrum provides everyone on the team a quick daily snapshot of where things stand on the project. This makes it the perfect time for the team to reconsider current assignments. For example, suppose Randy reports that the story he’s working on is taking much longer than he expected and Andrew reports that he is significantly ahead of schedule. In this case it may be appropriate for Andrew to spend the day paired with Randy and working on Randy’s tasks or for Andrew to outright take on responsibility for some of Randy’s tasks.
ScrumMaster 必须在每日站会期间小心行事。她需要保持轻快的步伐，但不能让会议感觉好像只是为了她的利益。一个永远不应该问的问题是“你还剩下多少时间在‘订购一本书’的故事上？” 此信息非常重要，但如果在每日站会期间要求提供，那么每日站会将变成关于估算和数字的全部内容。与每日 scrum 会议分开，我让团队在公共白板上或在我们使用的软件（如果我们不在同一地点）上更新他们的估计。
The ScrumMaster must walk a fine line during the daily scrums. She needs to keep the pace brisk but cannot let the meetings feel as though they are for her benefit alone. One question that should never be asked is “How much time do you have left on the ‘Order a book’ story?” This information is extremely important but if it is asked for during the daily scrum then the daily scrum will become all about estimates and numbers. Separate from the daily scrum meeting, I have the team update their estimates on a communal whiteboard or in the software we’re using if we’re not collocated.
将故事添加到 Scrum
Adding Stories to Scrum
在描述了一般的 Scrum 方法之后，我们现在将注意力转向如何通过将 Scrum 与故事的使用相结合来改进 Scrum。
Having described the general Scrum approach we now turn our attention to how Scrum can be improved by combining it with the use of stories.
故事和产品积压
Stories and the Product Backlog
我以用户故事的形式（ Cohn 2003 ）表达 Scrum 积压项目取得了巨大的成功。产品待办列表不允许描述新功能、要调查的问题、要修复的缺陷等，而是仅限于用户故事。产品待办事项列表中的每个故事都必须描述一些对用户或产品所有者有价值的项目。
I have had great success expressing Scrum backlog items in the form of user stories (Cohn 2003). Rather than allowing product backlog items to describe new features, issues to investigate, defects to be fixed, and so on, the product backlog is constrained to only user stories. Each story in the product backlog must describe some item of value to a user or to the product owner.
通过将产品待办事项限制为仅用户故事，产品所有者可以更轻松地确定待办事项的优先级。有了她可以理解的所有积压项目，产品负责人就可以很容易地做出用一个功能换另一个功能的决定。
By constraining the product backlog to only user stories it becomes much easier for the product owner to prioritize the backlog. With all backlog items in terms she can understand, it becomes easy for the product owner to make decisions to trade one feature for another.
与 XP 一样，在 Scrum 中，产品负责人预先确定所有需求并不重要。然而，一开始尽可能多地记下它们通常是有好处的。Scrum 没有规定，甚至没有推荐的方法来初始存储产品积压。传统上，这是通过产品所有者、ScrumMaster 和一个或多个开发人员之间的非结构化讨论来实现的。然而，我发现通过首先识别用户角色然后关注每个用户角色的故事，Scrum 结合了强大的需求识别技术。
As with XP, in Scrum it is not important for the product owner to identify all of the requirements up front. However, there is often a benefit to jotting down as many of them as possible at the outset. Scrum has no prescribed, or even recommended, approach to initially stocking the product backlog. Traditionally this has happened through an unstructured discussion between the product owner, ScrumMaster, and one or more developers. However, I’ve found that by first identifying user roles and then focusing on the stories for each user role, Scrum is combined with a powerful requirements identification technique.
Sprint 计划会议中的故事
Stories in the Sprint Planning Meeting
在冲刺计划会议期间，产品负责人和团队讨论产品待办列表中最优先的项目。然后团队确定他们将在冲刺期间承诺完成的项目。然后，他们根据需要将这些任务分解为更小的任务，以便开发人员可以在冲刺进行时注册任务。
During the sprint planning meeting, the product owner and team discuss the top priority items on the product backlog. The team then identifies the items they will commit to completing during the sprint. They then break those tasks into smaller tasks as necessary so that developers can sign up for tasks as the sprint progresses.
故事迫使每个产品积压项目都交付客户可以评估的价值。正因为如此，我发现冲刺计划会议比团队被迫解释技术驱动的积压项目（例如“重构登录类以引发异常”）的好处时更容易进行并且进行得更快。
Stories force each product backlog item to each deliver value that the customer can assess. Because of this I have found that sprint planning meetings are easier to conduct and go faster than when the team is forced to explain the benefit of technology-driven backlog items such as “refactor the Login class to throw an exception.”
故事也很适合冲刺计划，因为正如我们在第 10 章“计划迭代”中看到的那样，故事可以很容易地分解成它们的组成任务。
Stories also fit well into sprint planning because, as we saw in Chapter 10, “Planning an Iteration,” stories may be readily disaggregated into their constituent tasks.
Sprint 评审会议中的故事
Stories in the Sprint Review Meeting
在 sprint 评审会议期间使用故事有利于 Scrum，因为故事可以更简单地评估 sprint 的哪些部分已完成。在使用随机集合的技术任务、需求、问题和错误修复作为其产品待办列表的 Scrum 项目中，团队可能很难证明每个项目都进入了在该冲刺期间构建的产品中。当整个产品待办事项列表由描述客户或用户价值项目的故事组成时，通常更容易展示这些项目。
The use of stories benefits Scrum during the sprint review meeting because stories make it simpler to assess what parts of a sprint have been completed. On a Scrum project that uses a random collection of technical tasks, requirements, issues and bug fixes as its product backlog, it can be difficult for the team to demonstrate that each item made its way into the product built during that sprint. When the entire product backlog is composed of stories describing items of customer or user value, it is generally easier to demonstrate those items.
故事和每日 Scrum 会议
Stories and the Daily Scrum Meeting
我发现故事对每日 scrum 会议有益，因为它们有助于确保将重点放在客户和最终用户的需求上。因为在冲刺之前没有前期需求或分析阶段，所以冲刺开始时只是对将要构建的内容有部分了解。该团队可能知道他们正计划添加一个搜索屏幕，但他们可能不知道哪些字段将是可搜索的，如何组合搜索条件等等。故事很有用，因为它们提醒团队正在开发的内容背后的意图。在冲刺过程中，团队可以使用故事（以及与产品负责人就故事进行的持续讨论）来确定他们在编写特定故事时是否走得足够远，或者可能走得太远。
I have found stories beneficial to daily scrum meetings because they help ensure focus remains on customer and end-user desires. Because there is no upfront requirements or analyis phase that precedes a sprint, sprints are started with only a partial understanding of exactly what will be built. The team may know they are planning to add a search screen but they may not know what fields will be searchable, how search criteria may be combined, and so on. Stories are useful because they remind the team about the intent behind what is being developed. In the midst of a sprint the team can use the story (as well as ongoing discussions with the product owner about the story) to determine whether they have gone far enough, or perhaps too far, in programming a particular story.
案例研究
A Case Study
作为向 Scrum 添加故事的示例，让我们考虑一下我参与的一个项目。为方便起见，我们称他们为 Cosmodemonic Biotech，这是一家小型但上市的生命科学行业软件开发商。Cosmodemonic Biotech 刚刚完成了为期九个月的开发工作，为人类遗传学家推出了一种新产品。新产品交付到其最初的测试站点后不久，该公司宣布将被收购。
As an example of adding stories to Scrum, let’s consider a project I was involved in. The company, let’s call them Cosmodemonic Biotech for convenience, was a small but publicy-traded developer of software for the life sciences industry. Cosmodemonic Biotech had just completed a nine-month development effort to introduce a new product for human geneticists. Shortly after the new product was delivered to its initial beta site, the company announced that it was being acquired.
收购公司对产品附带的客户名单很感兴趣。但是，出于各种原因，他们决定需要重写该软件，包括：
The acquiring company was interested in the list of customers that came along with the product. However, they decided that the software would need to be rewritten for a variety of reasons, including:
- 原始产品 (HTML) 的客户端技术与新所有者的战略愿景不符
- the client technologies of the original product (HTML) did not fit well with the strategic vision of the new owner
- 该产品的目标市场从拥有数 TB 数据库的大型制药公司转变为拥有更小数据库的学术研究实验室和小型生物技术公司
- the target market for the product changed from very large pharmaceutical companies with multi-terabyte databases to academic research labs and small biotech companies with much smaller databases
- 大部分原始代码的实现相对较差
- a relatively poor implementation throughout much of the original code
最初的产品是在 9 个月的时间内以非常严格的瀑布方式开发的，团队有 100 名开发人员。新产品需要提供基本相同的功能，但团队规模不超过七人。
The original product had been developed in a very strict waterfall manner over a period of nine months with a team that was as large as 100 developers. The new product would need to deliver essentially the same functionality but would have a team size of no more than seven.
为实现这一目标，我们使用了 Scrum，并增加了本章中描述的用户故事。从各方面来看，该项目是成功的。Scrum 团队花了 12 个月的时间才完成瀑布团队在 9 个月内完成的工作。然而，由于 Scrum 团队从未超过 7 人，包括产品负责人和 ScrumMaster，因此该项目需要 54 个人月才能完成。瀑布版本耗时 540 人月完成。
To achieve this, we used Scrum augmented with user stories as described in this chapter. By all measures the project was a success. It took the Scrum team twelve months to complete what the waterfall team had done in nine. However, because the Scrum team never exceeded seven people, including the product owner and ScrumMaster, the project took 54 person-months to complete. The waterfall version had taken 540 person-months to complete.
瀑布团队产生了 58,000 个非注释 Java 源语句。Scrum with stories 团队事半功倍，产出了 51,000 个。这意味着瀑布团队每人每月产生 120 个 Java 源语句，而 Scrum 团队每人每月产生 840 个。这些比较显示在表 15.2中。
The waterfall team produced 58,000 non-comment Java source statements. The Scrum with stories team did more with less, and produced 51,000. This means the waterfall team produced 120 Java source statements per person-month while the Scrum team produced 840 per person-month. These comparisons are shown in Table 15.2.
表 15.2。 同一项目的两种方法的比较。
Table 15.2. Comparison of the two approaches to the same project.
概括
Summary
- Scrum 是一个迭代和增量过程。
- Scrum is an iterative and an incremental process.
- Scrum 项目在一系列称为冲刺的 30 天迭代中取得进展。
- Scrum projects progress in a series of thirty-day iterations called sprints.
- ScrumMaster 担任项目经理的角色，但更多的是领导者和促进者，而不是管理者。
- A ScrumMaster fills the project manager role but is more leader and facilitator than manager.
- 一个典型的 Scrum 团队包括四到七名开发人员。
- A typical Scrum team includes four to seven developers.
- 产品待办列表是尚未添加到产品或计划用于当前冲刺的所有所需功能的列表。
- The product backlog is a list of all desired features that have not yet been either added to the product or planned for the current sprint.
- sprint backlog 是团队为当前 sprint 承诺的任务列表。
- The sprint backlog is a list of tasks the team has committed to for the current sprint.
- XP 的客户角色由 Scrum 产品负责人扮演。
- XP’s customer role is played by the Scrum product owner.
- 产品负责人对产品待办事项进行优先级排序。
- The product owner prioritizes the product backlog.
- 在冲刺开始时，团队选择他们承诺在冲刺期间完成的工作内容和工作量。
- At the start of the sprint, the team selects what and how much work they commit to completing during the sprint.
- 举行简短的每日例会。在这些会议中，每个团队成员都会说出她昨天完成了什么，今天要完成什么，并指出她遇到的任何障碍。
- Brief daily scrum meetings are held. During these meetings each team member says what she completed yesterday, what she’ll complete today, and identifies any obstacles in her way.
- 每个冲刺负责产生一个潜在的可交付产品增量。
- Each sprint is responsible for producing a potentially shippable product increment.
- 在冲刺结束时，团队在冲刺审查会议上展示了它创建的软件。
- At the end of sprint, the team demonstrates the software it created in a sprint review meeting.
问题
Questions
15.1描述增量过程和迭代过程之间的区别。
15.1 Describe the differences between an incremental and an iterative process.
15.2 product backlog和sprint backlog有什么关系？
15.2 What is the relationship between the product backlog and the sprint backlog?
15.3潜在可交付产品增量是什么意思？
15.3 What is meant by a potentially shippable product increment?
15.4谁负责确定工作的优先级和选择团队在冲刺期间执行的工作？
15.4 Who is responsible for prioritizing work and for selecting the work the team will perform during a sprint?
15.5每个团队成员在每日站会上回答了哪些问题？
15.5 What questions are answered by each team member at the daily scrum?
第 16 章附加主题
Chapter 16. Additional Topics
在本书的这一部分，我们已经研究了一些在讨论用户故事时经常被提及的话题。我们已经研究了用户故事与其他需求方法有何不同，以及为什么在某些情况下用户故事更可取。我们已经了解了用户故事中的一些常见问题或问题，以及如何纠正它们。在本章中，我们将注意力转向几个附加主题：
Throughout this part of the book we have looked at some topics that are frequently raised whenever user stories are discussed. We’ve looked at how user stories differ from other requirements methods and why user stories are preferable in some cases. We’ve looked at some common smells, or problems, with user stories and how to correct them. In this chapter we turn our attention to several additional topics:
- 处理非功能性需求
- handling nonfunctional requirements
- 团队应该使用纸质记事卡还是软件
- whether teams should use paper note cards or software
- 用户故事对用户界面的影响
- the impact of user stories on the user interface
- 用户故事开发完成后是否应该保留
- whether user stories should be retained after they have been developed
- 错误报告和故事之间的关系
- the relationship between bug reports and stories
处理非功能性需求
Handling NonFunctional Requirements
团队开始使用用户故事的一个常见绊脚石是他们认为一切都必须作为用户故事来传达。大多数项目至少会遇到一些无法充分反映为故事的需求。这些通常是系统的非功能性需求。
A common stumbling block for teams getting started with user stories is their feeling that everything must be conveyed as a user story. Most projects will encounter at least a few requirements that cannot be adequately reflected as stories. Frequently these will be a system’s nonfunctional requirements.
非功能性需求可以解决各种系统需求。在以下领域可以找到一些更常见的非功能性需求类型：
Nonfunctional requirements can address a variety of system needs. Some of the more common types of nonfunctional requirements are found in the following areas:
- 表现
- performance
- 准确性
- accuracy
- 可移植性
- portability
- 可重用性
- reusability
- 可维护性
- maintainability
- 互操作性
- interoperabilty
- 可用性
- availability
- 可用性
- usability
- 安全
- security
- 容量
- capacity
许多非功能性需求可以被视为对系统行为的约束。例如，项目中包含诸如“系统应使用 Java 编写”之类的要求并不少见。这显然是对系统其余部分设计的限制。正如第 7 章“好故事的指南”中所讨论的，约束的最佳处理方式是将约束写在卡片上并在卡片上标注“约束”。在大多数情况下，可以编写（并至少每天运行一次）自动化测试以确保遵守约束。一些约束无法实际测试或不值得测试。我想到了“系统应使用 Java 编写”这一约束条件。当然有一些简单的方法可以确保满足此约束。
Many nonfunctional requirements can be considered as constraints on the system’s behavior. For example, it is not uncommon for a project to include a requirement such as “The system shall be written in Java.” This is clearly a constraint on the design of the rest of the system. As discussed in Chapter 7, “Guidelines for Good Stories,” constraints are best handled by writing the constraint on a card and annotating the card with “Constraint.” In most cases, an automated test can be written (and run at least daily) to ensure compliance with a constraint. A few constraints cannot be realistically tested or are not worth testing. The constraint “The system shall be written in Java” comes to mind. There are certainly easy ways to ensure this constraint is satisfied.
表 16.1中显示了一些常见约束的示例。除了在卡片上写约束之外，如果系统必须遵守额外的非功能性要求，则以任何适当或传统的形式传达它们。例如，如果项目可以从显示系统中所有变量的大小和类型的数据字典中获益，那么就创建一个数据字典。
Examples of some common constraints are shown in Table 16.1. Beyond writing constraints on a card, if there are additional nonfunctional requirements that a system must adhere to, then communicate them in whatever form is appropriate or traditional. If, for example, the project can benefit from a data dictionary showing the size and type of all variables in the system, then create a data dictionary.
表 16.1。 为各种常见的非功能性需求编写的示例约束。
Table 16.1. Sample constraints written for a variety of common nonfunctional requirements.
论文还是软件？
Paper or Software?
甚至比被问到“纸还是塑料？”更常见 在杂货店，问题是故事应该写在纸质记事卡上还是存储在软件系统中。极限编程社区中的许多人都提倡使用纸质记事卡，因为它们很简单。极限编程非常重视简单的解决方案，而纸质记事卡绝对是简单的。此外，卡片鼓励互动和讨论。它们可以在计划时以各种形式放置在桌子上，可以堆叠和分类，可以携带到任何会议中，等等。
Even more common than being asked “paper or plastic?” at the grocery store is the question of whether stories should be written on paper note cards or stored in a software system. Many in the Extreme Programming community advocate the use of paper note cards because of their simplicity. Extreme Programming places a premium on simple solutions, and paper note cards are definitely simple. Additionally, cards encourage interaction and discussion. They can be placed on a table in various formations during planning, they can be stacked and sorted, they can be carried into any meeting, and so on.
另一方面，有专为跟踪故事而设计的软件产品（VersionOne，[1]规划师，[2]选择范围管理器[3] ) 以及可与故事一起使用的通用软件（电子表格、缺陷跟踪器和维基）。
On the other hand, there are software products designed specifically for tracking stories (VersionOne,[1] XPlanner,[2] Select Scope Manager[3]) as well as general purpose software that can be used with stories (spreadsheets, defect trackers and wikis).
卡片相对于软件的主要优势之一是它们的低技术性质不断提醒人们故事是不精确的。当在软件中显示时，故事可能会呈现 IEEE 830 风格要求的外观，而那些编写故事的人可能会因此添加额外的、不必要的细节。
One of the main advantages that cards have over software is that their low-tech nature is a constant reminder that stories are imprecise. When shown in software, stories may take on the appearance of IEEE 830-style requirements and those writing stories may add additional, unnecessary detail because of that.
典型的记事卡只能容纳有限数量的文字。这给了它一个自然的文本量上限。大多数软件替代品中不存在此限制。另一方面，那些人之间的普遍做法使用记事卡就是在卡片背面为一个故事写一些样本验收测试。在许多情况下，在编写测试用例时，卡的大小可能会对其产生不利影响。
The typical note card can hold a limited amount of writing. This gives it a natural upper limit on the amount of text. This limitation does not exist in most software alternatives. On the other hand, a common practice among those using note cards is to write some sample acceptance tests for a story on the back of the card. In many cases, the size of the card can work against it when writing the test cases.
在 ClickTactics 选择软件
ClickTactics 是一家营销解决方案提供商，编写可通过网络访问的软件组件。他们从记事卡开始，但从 VersionOne 转向软件 V1:XP。
ClickTactics is a marketing solutions provider that writes web-accessible software components. They started with note cards but switched to software, V1:XP from VersionOne.
ClickTactics 的高级产品经理 Mark Mosholder 说，改变的原因之一是他们的销售人员和高层管理人员分布在多个站点。对于远程利益相关者，他们不能说“去看看董事会”，所以他们花了很多时间更新高级管理人员和其他远程利益相关者。此外，在使用记事卡时，他们遇到卡片偶尔会丢失的问题，然后在数周后在桌子下的一堆中找到。
Mark Mosholder, Senior Product Manager at ClickTactics, says one reason for the change is that their sales force and upper management are distributed across multiple sites. With remote stakeholders they could not say “go look at the board” so they spent a lot of time updating senior management and other remote stakeholders. Also, when using note cards they had problems with cards occasionally getting lost and then found weeks later in a pile under a desk.
在 VersionOne 软件中保留故事使 ClickTactics 能够推广他们将 XP 用作销售工具。使用该软件，他们让一些客户有限地了解他们的迭代。然后，他们通过告诉客户“我们可以在三周内为您提供新功能”来提高为客户推出新版本的速度。
Keeping stories in the VersionOne software allowed ClickTactics to promote their use of XP as a sales tool. Using the software, they give some customers limited visibility into their iterations. They then promote the speed with which they can turn around new versions for customers by telling them, “We can get you new functionality in three weeks.”
马克说他们的决定没有任何缺点，并表示他会再次做出同样的决定。
Mark says there have been no drawbacks to their decision and says he would make the same decision again.
追求 ISO（国际标准化组织）或类似认证的项目需要从需求声明到代码和测试的可追溯性，这可能会偏爱软件。手写记事卡应该可以获得 ISO 认证，但是对一副卡片实施和展示适当的变更控制程序可能比卡片可能具有的其他优势更重要。
A project pursuing ISO (International Organization for Standardization), or similar, certification that requires traceability from a requirement statement down through code and tests will probably favor software. It should be possible to achieve ISO certification with handwritten note cards, but putting in place and demonstrating adequate change control procedures over a deck of cards probably outweighs the other advantages cards may have.
同样，一个不在同一地点的团队可能更喜欢软件而不是记事卡。当一个或多个开发人员（尤其是客户）处于远程位置时，使用纸张进行工作太困难了。
Similarly, a team that is not collocated will probably prefer software over note cards. When one or more developers, or especially the customer, is remote, it is too hard to work with paper.
记事卡的另一个优点是它们非常容易分类，并且可以用多种方式分类。可以将故事集合分类为高、中和低优先级堆。或者可以将它分类为更精确的顺序，第一个故事的优先级高于第二个故事，第二个故事的优先级高于第三个故事，依此类推。
An additional advantage to note cards is that they are very easy to sort and can be sorted in a variety of ways. A collection of stories can be sorted into high, medium and low priority piles. Or it could be sorted into more precise order with the first story higher priority than the second and the second higher priority than the third and so on.
与这两种技术的许多最虔诚的支持者不同，我认为这两种方法都适用。我建议从卡片开始并查看它们在您的环境中如何工作。然后，如果有令人信服的理由使用软件，请切换。
Unlike many of the most devout supporters of either technique, my opinion is that both approaches can be appropriate. I recommend starting with cards and seeing how they work in your environment. Then, if there’s a compelling reason to use software, switch.
在 Diaspar Software Services 使用 Wiki
JB Rainsberger 是软件开发和咨询公司 Diaspar Software Services 的创始人。作为一名顾问，JB 不能总是在客户现场。在那些情况下，JB 使用 wiki 来改善他与远程客户之间的沟通。wiki 是一组特殊的网页，任何查看该网页的人都可以对其进行编辑。JB 和 Diaspar Software 使用 FitNesse 作为他们的 wiki。他们不是为每个故事都写一张故事卡，而是为每个故事创建一个新页面。
J. B. Rainsberger is the founder of Diaspar Software Services, a software development and consulting company. As a consultant, J. B. cannot always be on-site with his customers. In those situations, J. B. uses a wiki to improve communication between himself and his remote customer. A wiki is a set of special web pages that can be edited by anyone viewing the page. J. B. and Diaspar Software use FitNesse as their wiki. Rather than writing a story card for each story they create a new page for each story.
JB 报告说这在最近的一个小项目中非常有效。当他对一个故事有疑问时，他会在页面上注明问题并添加文本“待办事项”。他的客户每周会检查 wiki 数次，搜索“待办事项”并回答问题。紧急问题电话处理；但由于使用 wiki 的效率，紧急问题出奇地少。JB 曾在其他项目中使用过纸质记事卡，但报告说，在这个项目中，与其远程客户一起，他从来没有希望将故事写在卡片和维基中。
J. B. reports that this worked extremely well on a recent small project. As he had questions about a story he would note the question on the page and add the text “todo.” Several times a week his customer would check the wiki, search for “todo,” and answer the questions. Urgent issues were handled by phone; but because of the efficiencies of using a wiki there were surprisingly few urgent issues. J. B. has worked with paper note cards on other projects but reports that on this project, with its remote customer, there was never a time when he wished he had the stories on cards as well as in the wiki.
尽管 JB 使用 FitNesse wiki 为每个项目编写可执行测试，但他指出“让每个人都在房间里就没有必要将故事放在 wiki 上。”
Although J. B. uses the FitNesse wiki for writing executable tests for every project, he points out that “having everyone in the room makes it unnecessary to put stories on a wiki.”
用户故事和用户界面
User Stories and the User Interface
有人指出，敏捷方法在很大程度上忽略了设计用户界面的问题。在某种程度上，这是可以理解的：敏捷过程是高度迭代的，而传统的用户界面设计方法已经大爆炸，严重依赖于前期设计。重要的是要了解为具有重要或重要用户界面的应用程序采用基于故事的敏捷方法的潜在风险。
It has been pointed out that agile methods largely ignore issues of designing the user interface. To some extent this is understandable: Agile processes are highly iterative, while traditional approaches to user interface design have been big-bang with heavy reliance on upfront design. It is important to understand the potential risks in pursuing an agile story-based approach for an application with a significant or important user interface.
我们可以迭代地改进系统，这是敏捷开发的原则之一。用户故事允许我们将对话推迟到开发人员准备为程序添加对故事的支持之前不久。有时推迟这些对话会导致开发人员稍微修改应用程序的现有部分；但人们相信，这些轻微返工的成本与不进行需求讨论所节省的成本相比是合理的关于稍后将被删除的功能，以及允许客户通过许多较小的路线更正来引导产品的好处。
It is one of the tenets of agile development that we may iteratively refine a system. User stories allow us to defer conversations until shortly before the developers are ready to add support for the story to the program. Sometimes deferring these conversations causes the developers to slightly rework existing parts of an application; but the belief is that the cost of these slight reworkings is more than justified by the savings in not holding requirements discussions about features that will later be dropped, and by the benefits of allowing the customer to steer the product with many smaller course corrections.
如果这些变化发生在应用程序的用户界面之下，那么这种看法可能是正确的。但是，当这些更改影响到用户界面时会发生什么？Larry Constantine (2002) 写道：
If these changes happen beneath the user interface of an application then this belief may be true. However, what happens when these changes affect the user interface? Larry Constantine (2002) writes that:
对于用户界面，架构——整体组织、导航和外观——必须设计成适合要涵盖的全部任务。当涉及到用户界面时，架构的后期细化是不可接受的，因为这意味着为已经学习或掌握了早期界面的用户更改系统。即使对功能的位置或形式进行微小的调整也会给用户带来问题。
For user interfaces, the architecture—the overall organization, the navigation, and the look–and–feel—must be designed to fit the full panoply of tasks to be covered. When it comes to the user interface, later refinement of the architecture is not as acceptable because it means changing the system for users who have already learned or mastered an earlier interface. Even small adjustments in the placement or form of features can be problematic for users.
这意味着如果用户界面对我们产品的成功很重要，那么我们可能需要从一开始就考虑用户界面。如果更改用户界面会给用户带来问题，那么可能对项目有一个不成文的约束——“一旦开始就尽可能少地更改用户界面”。
This means that if the user interface will be important to the success of our product, then we might need to think about the user interface right from the start. If changing the user interface will cause problems for users then there is probably an unwritten constraint on the project—“Change the user interface as little as possible once it’s started.”
Constantine 和 Lockwood (2002) 提出敏捷的以使用为中心的设计作为解决方案。以使用为中心的敏捷设计是由基本用例或任务用例而不是用户故事驱动的。然而，我们可以用故事代替基本用例，这导致以下基于故事的敏捷使用为中心设计的变体：
Constantine and Lockwood (2002) propose agile usage-centered design as a solution. Agile usage-centered design is driven by essential use cases or task cases rather than user stories. However, we can replace essential use cases with stories, which leads to the following story-based variation on Agile Usage-Centered Design:
1. 执行用户角色建模。
1. Perform user role modeling.
2. 搜索高级用户故事。
2. Trawl for high-level user stories.
3. 优先考虑故事。
3. Prioritize stories.
4. 优化高优先级和中优先级的故事。
4. Refine high- and medium-priority stories.
5. 将故事组织成组。
5. Organize stories into groups.
6. 创建纸质原型。
6. Create a paper prototype.
7. 完善原型。
7. Refine the prototype.
8. 开始编程。
8. Start programming.
第一步是召开用户角色建模会议，正如第 3 章“用户角色建模”中所述。要完成接下来的几个步骤，请启动第 4 章“收集故事”中所述的故事写作研讨会。在研讨会中，最初的重点是捕捉最高级别的故事，可能不超过两打。
The first step is to hold a user role modeling session, exactly as described in Chapter 3, “User Role Modeling.” To complete the next few steps, initiate a story-writing workshop as described in Chapter 4, “Gathering Stories.” In the workshop focus initially on capturing the highest-level stories, probably no more than two dozen.
接下来，将高级别故事分为三组：高优先级故事必须在即将发布的版本中，中优先级故事需要在即将发布的版本中发布，低优先级故事可以推迟到后续版本发布。将低优先级的故事放在一边，同时将高优先级和中优先级的故事提炼成更小的故事。这些故事应该是您在计划发布时将使用的大小。
Next, prioritize the high-level stories into three groups: High-priority stories must be in the upcoming release, medium-priority stories are desired for the upcoming release, and low priority stories can be deferred until a subsequent release. Put the low priority stories aside while refining the high- and medium-priority stories into smaller stories. These stories should be the size you will work with in planning the release.
接下来，将高优先级和中优先级的故事组织成一组，这些故事很可能一起表演。然后，在纸上为每组故事绘制原型。创建纸质原型后，将它们展示给用户（或必要时的用户代理）并根据他们的评论改进原型。
Next, organize the high- and medium-priority stories into groups that have a high likelihood of being performed together. Then, draw prototypes on paper for each group of stories. After creating the paper prototypes, show them to users (or user proxies if necessary) and refine the prototypes based on their comments.
如果您将这些步骤添加到您的项目中，请记住尽可能使过程轻量级。一些已确定并正在原型化为用户界面的故事最终可能会在开发之前从项目中删除。避免花费不必要的时间。对于大多数应用程序，这可能需要几天到不超过几周的时间（对于具有远程用户的商业软件）。
If you add these steps to your project, remember to keep the process as lightweight as you can. Some of the stories that were identified and that are being prototyped into a user interface could end up being removed from the project before they get developed. Avoid spending any more time than necessary. For most applications, this may entail somewhere from a few days to no more than a few weeks (for commercial software with remote users).
写二
几年前，我在做一个项目，我们请沃德·坎宁安 (Ward Cunningham) 来咨询和评估该项目。当时，团队正在努力解决有关用户界面的问题。关于用户是更喜欢基于浏览器的界面还是更喜欢本地应用程序，存在许多激烈的争论。我们的营销团队询问了用户，但我们不确定他们是否调查了足够多的用户，或者他们是否以正确的方式进行了研究。
A few years ago I was working on a project and we brought Ward Cunningham in to consult and assess the project. At the time the team was struggling with questions about the user interface. There were many hot-and-heavy debates about whether users would prefer a browser-based interface or whether they’d prefer a native application. Our marketing group had asked the users but we weren’t confident that they had surveyed enough users or that they’d done the research the right way.
Ward 通过告诉我们“写两个用户界面”来解决这个问题。他的逻辑是，两者都不难编写，并且在两者之间，它们将保持应用程序的中间层诚实。对于两个用户界面，没有任何功能会不适当地移动到客户端层，如果这样做意味着必须编写两次功能。
Ward settled the question by telling us “Write two user interfaces.” His logic was that neither would be hard to write and between the two of them, they would keep the application’s middle-tier honest. With two user interfaces no functionality would be inappropriately moved to the client tier if doing so meant that functionality would have to be written twice.
沃德的建议是对的。当然，我们没有听，认为开发两个完整的用户界面太昂贵了。当产品完成时，我们的客户告诉我们我们确实选择了错误的用户界面技术。并且很快开始了一个项目来添加第二个用户界面。
Ward’s suggestion was right. We, of course, failed to listen, thinking it would be too expensive to develop two complete user interfaces. When the product was finished our customers let us know that we had indeed chosen the wrong user interface technology. And a project was quickly begun to add a second user interface.
保留故事
Retaining the Stories
关于是否应该保留故事的争论很常见。一方面有人说撕掉一张完整的卡片的乐趣超过保留卡片的任何价值。相反的是更保守的人群，他们宁愿保存故事，也不愿冒险将其丢弃，以后再需要它。
Arguments over whether stories should be retained are common. On one side are those who say that the pleasure of ripping up a completed card outweighs any value of retaining the card. On the opposite side is the more conservative crowd who would rather save the story than risk throwing it away and then needing it later.
如果您使用软件来保存您的故事，则没有理由摆脱已完成的故事。您可能会从删除电子故事中获得一些乐趣和结束感，但它可能不如将实体卡片撕成两半的发自内心的快感。
If you’re using software to hold your stories there is very little reason to get rid of completed stories. You may get some pleasure and feelings of closure from deleting an electronic story but it’s probably not as great as the visceral pleasure of ripping a physical card in half.
如果您使用的是纸质记事卡，那么完成一张卡片并将其撕成两半确实会带来切实的乐趣。我用卡片来指导这本书的写作，每次我完成一个新的部分或修订时，我都会撕掉卡片。然而，当我从事软件项目而不是书籍时，我更喜欢保留卡片，用橡皮筋将它们归档在架子上。
If you’re using paper note cards, then there can indeed be a tangible pleasure associated with finishing a card and ripping it in half. I’ve used cards to guide the writing of this book and each time I complete a new section or revision I rip up the card. However, when I’m working on a software project, rather than a book, I prefer to retain the cards, archiving them on a shelf with a rubber band.
多年来，我参与了一些情况，我很庆幸我保留了这些要求。以下是一些案例：
Over the years I’ve been involved in a handful of situations where I’ve been thankful that I retained the requirements. Here are some of the cases:
- 我工作的公司被收购了。收购公司对我们的轻量级软件开发过程很感兴趣，但他们有自己的高度以瀑布为导向的方法，每个项目都必须通过许多关卡和签收点。因为我能够实际向他们展示我们的流程（从故事到代码和测试），他们允许我们继续我们的流程而不是采用公司范围的标准。更好的是，我们最终能够在将我们的流程扩展到公司的其他部门方面取得一些进展。
- The company I was working for was being bought. The acquiring company was intrigued by our lightweight software development process but they had their own heavily waterfall-oriented approach with numerous gates and sign-off points each project had to pass through. Because I was able to actually show them our process (from stories to code and tests) they allowed us to continue with our process and not adopt the company-wide standard. Even better, we were eventually able to make some inroads in spreading our process into other divisions of the company.
- 我曾多次参与完全重写商业产品。在一个案例中，由于某些糟糕的技术选择，产品的第一个版本在商业上失败了。该产品被完全重写并取得了一定的成功。另一个产品作为客户端-服务器应用程序取得了惊人的成功，五年后，公司希望重写它并在 Web 上提供。每当有过时的故事或需求时，它们都会很有用。
- On a number of occasions I’ve been involved in completely rewriting commercial products. In one case the first version of a product was a commercial failure because of some poor technology choices. The product was completely rewritten and became a moderate success. Another product was a phenomenal success as a client-server application, and five years later the company wanted it rewritten and available on the web. Whenever there were even outdated stories or requirements, they were useful to have around.
- 在另一种情况下，我参与了一家试图与一家大得多的公司达成交易的小型初创公司。如果交易完成，它将推动公司进入盈利领域，老板还承诺向所有开发商提供五位数的高额奖金。我们被要求“提供要求的副本。” 我开始描述我们如何没有真正专注于书面需求，而是专注于对话和协作。我能感觉到谈话不会顺利结束，公司的盈利能力和开发人员的巨额奖金正在蒸发。我换档并告诉他们我们如何以用户故事的形式编写需求。他们喜欢这个主意。幸运的是，我们的故事以电子方式存储在该项目中。我们将它们从它们所在的系统中剪切下来，粘贴到 Word 文档中，添加了封面和签名页，每个人都很高兴。
- In yet another situation I was involved with a small startup that was trying to close a deal with a much larger company. If the deal was closed it would push the company into profitable territory, and the boss was also promising high five-digit bonuses to all of the developers. We were asked to “provide a copy of the requirements.” I started to go down the road of describing how we didn’t really focus on written requirements and that we instead focused on conversation and collaboration. I could sense the conversation was not going to end well and that company profitability and the large developer bonuses were evaporating. I shifted gears and told them how we wrote requirements in the form of user stories. They liked the idea. Fortunately our stories were stored electronically on that project. We cut them from the system they were in, pasted them into a Word document, added a cover page and a signature page and everyone was happy.
考虑到我发现保留故事有用的各种场合，我的建议是您也这样做。如果您使用的是软件，请保持安装该软件或从中打印报告并将报告存档在某处。如果你使用的是卡片，要么自己保存卡片，要么一次复印三张卡片到纸上。
Considering the variety of occasions on which I’ve found it useful to have retained stories, my recommendation is that you do so as well. If you’re using software, either keep the software installed or print a report from it and file the report somewhere. If you’re using cards, either save the cards themselves or photocopy them three at a time onto paper.
Bug 的故事
Stories for Bugs
一个非常常见的问题是故事和错误报告之间的关系。我发现最有效的方法是考虑每个错误报告都有自己的故事。如果修复错误的时间可能与典型故事一样长，则可以像对待任何其他故事一样对待该错误。但是，对于团队希望能够快速修复的错误，您应该将这些错误组合到一个或多个故事中。使用卡片，您可以通过将故事卡片与封面故事卡片装订在一起来轻松做到这一点。然后，出于计划的目的，错误的集合可能被视为一个故事。
A very common question is the relationship between stories and bug reports. What I’ve found to work best is to consider each bug report its own story. If fixing a bug is likely to take as long as a typical story, that bug can be treated just like any other story. However, for bugs that the team expects to be able to fix quickly, you should combine the bugs into one or more stories. With cards you can easily do this by stapling the story cards together along with a cover story card. Then, for planning purposes, the collection of bugs may be treated as a single story.
颜色呢？
一些团队喜欢使用不同颜色的卡片来指示卡片上的故事类型。例如，传统的白卡可用于普通故事。红色卡片可用于错误，蓝色卡片可用于工程任务等。
Some teams favor using cards of different colors to indicate the type of story on the card. For example, traditional white cards could be used for normal stories. Red cards could be used for bugs, blue cards could be used for engineering tasks and so on.
对我来说，使用彩色卡片在理论上似乎总是一个好主意；但在实践中不值得为此付出额外的努力。我不能只在口袋里放几张白卡，我必须确保每种颜色都随身携带几张。如果我用完所有可用的东西来写故事，那么我需要稍后重写这个故事。但是，如果您认为颜色可以帮助您组织故事，请尝试一下。我会坚持使用简单的东西——一大堆白牌。
To me, using colored cards always seems like a good idea in theory; but in practice is not worth the extra hassle. Instead of just keeping a supply of white cards in my pocket, I have to make sure to always carry a few of each color. If I run out and write the story on whatever is available I then need to rewrite the story later. But if you think colors will help you organize your stories, try it. I’ll stick to what’s simple—a huge pile of white cards.
概括
Summary
- 非功能性需求（例如性能、准确性、可移植性、可重用性、可维护性、互操作性、容量等）通常可以通过创建约束卡来处理。如果系统的要求比这更复杂，请使用最能表达这些要求的任何其他格式或技术来补充您的用户故事方法。
- Nonfunctional requirements (such as for performance, accuracy, portability, reusability, maintainability, interoperability, capacity and so on) can often be handled by creating constraint cards. If the system has requirements that are more complex than this, supplement your user story approach with whatever additional format or technique best expresses those requirements.
- 在所有情况下，记事卡或软件系统都不是编写故事的最佳方式。将工具与项目和团队相匹配。
- Neither note cards nor a software system is the best way to write stories in all cases. Match the tool to the project and team.
- 迭代过程可以导致用户界面中的迭代变化。习惯了界面非常具体的方面的用户不喜欢影响他们学习操作软件方式的用户界面变化。考虑从以敏捷使用为中心的设计中添加一些实践，以避免迭代用户界面。
- An iterative process can lead to iterative changes in the user interface. Users, who become accustomed to very specific aspects of the interface, do not like user interface changes that affect how they have learned to operate the software. Consider adding some practices from Agile Usage-Centered Design to avoid iterating the user interface.
- 故事卡一完成就撕掉是一种乐趣。但也有保留卡片的理由。为了安全起见，保留故事。
- There’s a certain joy in ripping up a story card as soon as it’s complete. But there are also reasons to retain the cards. Err on the safe side and retain the stories.
- 将小错误报告与封面故事卡一起装订，并将它们视为一个故事。
- Staple small bug reports together with a cover story card and treat them as a single story.
开发者责任
Developer Responsibilities
- 您有责任在适当的时候建议和使用替代技术和方法来表达需求。
- You are responsible for suggesting and using alternative techniques and methods for expressing requirements when appropriate.
- 您有责任决定什么适合您的项目：记事卡或软件系统。
- You share a responsibility to decide what is right for your project: note cards or a software system.
- 您有责任了解在项目开始时考虑整体用户界面的优点和缺点。
- You share a responsibility for understanding the advantages and disadvantages of considering the overall user interface at the start of the project.
客户责任
Customer Responsibilities
- 如果您认为用户故事不能准确反映需求的某些部分，您有责任请求或使用替代技术和方法来表达需求。
- You are responsible for requesting or using alternative techniques and methods for expressing requirements if you do not feel user stories are accurately reflecting some part of the requirements.
- 您有责任决定什么适合您的项目：记事卡或软件系统。
- You share a responsibility to decide what is right for your project: note cards or a software system.
- 您有责任了解在项目开始时考虑整体用户界面的优点和缺点。
- You share a responsibility for understanding the advantages and disadvantages of considering the overall user interface at the start of the project.
问题
Questions
16.1你应该如何处理系统扩展到 1000 个并发用户使用的需求？
16.1 How should you handle a requirement for a system to scale up to use by 1,000 concurrent users?
16.2你更喜欢在笔记卡上还是在软件系统中写故事？捍卫你的答案。
16.2 Do you prefer to write stories on note cards or in a software system? Defend your answer.
16.3迭代过程对应用程序的用户界面有什么影响？
16.3 What impact does an iterative process have on the user interface of an application?
16.4给出一些系统示例，这些系统可以从比敏捷项目中通常给出的用户界面更多的前期考虑中获益。
16.4 Give some examples of systems that could benefit from more upfront consideration of the user interface than is typically given on an agile project.
16.5你建议在故事开发完成后保留还是丢弃故事？捍卫你的答案。
16.5 Do you recommend retaining or disposing of stories once the story has been developed? Defend your answer.
第四部分：一个例子
Part IV: An Example
第四部分将所有内容整合到一个综合示例中。在接下来的章节中，您将遇到 South Coast Nautical Supplies 及其一些员工，因为他们创建了一个网站来扩充他们的印刷目录。您将有机会确定用户角色，与 Lori（South Coast 的销售和营销副总裁兼该项目的客户）一起编写故事，估算故事，制定发布计划，然后为故事编写一些验收测试最初的计划。
Part IV brings everything together in a comprehensive example. In the chapters that follow, you’ll meet South Coast Nautical Supplies and some of its employees as they create a website to augment their print catalog. You’ll have the opportunity to identify user roles, write stories with Lori (South Coast’s vice president of Sales and Marketing and the customer for this project), estimate the stories, create a release plan and then write some acceptance tests for the stories in the initial plan.
第 17 章用户角色
Chapter 17. The User Roles
在接下来的五章中，我们将进行一个小型的假设项目。在本章中，我们将从识别关键用户角色开始。在后续章节中，我们将继续编写故事、估算故事、计划发布以及为发布中的故事编写验收测试。
Over the course of the next five chapters we will undertake a small, hypothetical project. In this chapter we’ll start by identifying the key user roles. In subsequent chapters we’ll move on to writing stories, estimating the stories, planning a release, and writing acceptance tests for the stories in the release.
该项目
The Project
我们公司 South Coast Nautical Supplies 三十年来一直通过印刷目录销售航海用品。我们的目录包括全球定位系统、时钟、气象设备、导航和绘图设备、救生筏、充气背心、图表、地图和书籍等项目。到目前为止，我们的 Internet 存在一直是一个简单的单页站点，引导人们拨打免费电话以请求目录。
Our company, South Coast Nautical Supplies, has been selling sailing supplies through a print catalog for thirty years. Our catalogs feature items such as Global Positioning Systems, clocks, weather equipment, navigation and plotting equipment, life rafts, inflatable vests, charts, maps and books. So far our Internet presence has been a simple one-page site directing people to call a toll-free number to request a catalog.
我们的老板决定我们终于应该与时俱进，开始在互联网上销售东西。然而，他希望我们先从销售书籍开始，而不是从销售我们的一些大件商品开始。我们目录中的某些商品价格超过 10,000 美元，在我们知道我们的网站运行良好并且不会丢失订单之前，我们不想为昂贵的商品承担任何风险。但是，如果我们发现我们的客户喜欢能够在线订购，并且如果我们在网站上做得很好，我们就会在网站上扩展和销售我们的其余产品。
Our boss has decided we should finally get with the times and start selling things over the Internet. However, rather than start by selling some of our bigger ticket items, he wants us to start by selling just books. Some items in our catalog cost over $10,000 and until we know our site works well and doesn’t lose orders, we don’t want to take any risk with expensive items. But if we find that our customers like being able to order online, and if we do a good job on the site, we’ll expand and sell the rest of our products on the site.
哦，老板说的最后一件事是网站需要在 30 天内上线，这样我们才能在夏季航行高峰期增加销售额。
Oh, and the last thing the boss says is that the site needs to be live in thirty days so we can capture increased sales during the peak summer sailing months.
识别客户
Identifying the Customer
该项目需要客户帮助我们识别和编写故事。该产品的客户是购买书籍的水手，他们都在外面公司。因此，我们需要一个内部客户来充当真正的最终用户客户的代理。为此，老板指定了销售和营销副总裁 Lori。
The project needs a customer to help us identify and write stories. The customers for this product are the sailors who buy the books and they are all outside the company. So, we need an internal customer who can act as a proxy for the real end-user customers. For this the boss designates Lori, who is the vice president of Sales and Marketing.
在与 Lori 的初次会面中，她提供了有关她所需系统的更多背景信息。她想要一个“典型的书店/电子商务网站”。她希望客户能够以多种方式搜索书籍（我们目前不要求澄清），她希望用户能够维护他们以后要购买的书籍列表，她希望用户评价并评论他们购买的书籍，她想让他们的用户检查订单的状态。我们已经看到很多这样的网站，所以我们告诉 Lori 我们已经准备好开始了。
In an initial meeting with Lori she provides more background on the system she needs. She wants a “typical bookstore/eCommerce site.” She wants customers to be able to search for books in a variety of ways (we don’t push for clarification at this point), she wants users to be able to maintain lists of books they’ll buy later, she wants users to rate and review books they buy, and she wants to them users check on the status of an order. We’ve seen plenty of sites like this so we tell Lori we’re ready to start.
确定一些初始角色
Identifying Some Initial Roles
我们做的第一件事是将一些开发人员和 Lori 聚集在一个有大桌子的房间里。Lori 已经研究过市场并了解我们典型客户的人口统计数据。Lori和开发人员编写了以下用户角色卡，其放置方式如图17.1所示：
The first thing we do is gather some of the developers together with Lori in a room with a large table. Lori has already researched the market and knows the demographics of our typical customers. Lori and the developers write the following user role cards, which are placed as shown in Figure 17.1:
- 铁杆水手
- Hardcore Sailor
- 新手水手
- Novice Sailor
- 新水手
- New Sailor
- 礼品买家
- Gift-Buyer
- 非航海配偶
- Non-Sailing Spouse
- 行政人员
- Administrator
- 销售副总裁
- Sales Vice President
- 船长
- Charter Captain
- 经验丰富的水手
- Experienced Sailor
- 帆船学校
- Sailing School
- 图书馆
- Library
- 讲师
- Instructor
图 17.1。 定位用户角色卡。
Figure 17.1. Positioning the user role cards.
巩固和缩小
Consolidating and Narrowing
将用户角色名称写在卡片上后，我们需要删除重复或近似重复的内容，考虑是否应合并任何角色，并提出项目将开始的用户角色的细化列表。最简单的开始方法是尝试移除完全放在另一张卡片上的任何卡片，表明其作者认为它们是重复的。
After the user role names are written on cards we need to remove duplicates or near duplicates, consider whether any roles should be merged, and come up with a refined list of user roles that the project will start with. The easiest way to start is by trying to remove any card that is placed entirely on top of another card, indicating that its author thought they were duplicates.
在这种情况下，New Sailor 卡已放置在 Novice Sailor 卡之上。这些卡片的作者解释了他们的意图，其他任何人都可以添加他们想要的任何评论。原来，新手水手和新水手是有区别的。新水手是指对航海运动不熟悉的人；也许她目前正在上课或已经航行了几次。新手水手卡的作者实际上是指这个角色代表可能已经航海多年但还不够频繁而无法熟练掌握的人。该小组决定，尽管这些角色看起来略有不同，但它们的不同程度还不足以让他们担任两个角色。他们合并为一个角色，Novice Sailor，New Sailor 卡被撕毁并扔掉。
In this case, the New Sailor card has been placed on top of the Novice Sailor card. The authors of those cards explain what they intended by them, and anyone else adds any remarks they wish. It turns out that there is a distinction between a Novice Sailor and a New Sailor. A New Sailor is someone who is new to the sport of sailing; perhaps she is currently taking lessons or has sailed a few times. The author of the Novice Sailor card actually meant that role to represent someone who may have been sailing for years but just not often enough to have become good at it. The group decides that although these roles appear to be slightly different, they are not sufficiently different that it is worth having two roles for them. They are merged together in a single role, Novice Sailor, and the New Sailor card is torn up and thrown away.
接下来，小组考虑重叠的帆船学校和教练卡。教练卡的作者解释说，该角色代表教授航海课程的水手。她认为，教师经常为学生购买书籍副本，或者可能会列出学生正在阅读的书籍清单。需要阅读。帆船学校角色卡的作者表示，这部分是她对该卡的意图。然而，她认为典型的用途是学校的管理人员而不是航海教练本人。客户 Lori 通过告诉我们即使是学校管理员，管理员也将具有许多与教师相同的特征，从而为我们澄清了这一点。由于教练比帆船学校更明显是一个人，所以帆船学校的卡片被撕掉了。
Next, the group considers the overlapping Sailing School and Instructor cards. The author of the Instructor card explains that the role represents sailors who teach sailing classes. Instructors, she argues, frequently buy copies of books for their students or perhaps assemble lists of books that students are required to read. The author of the Sailing School role card indicates that this is partially what she intended for that card. However, she thought that typical use would be by an administrator at the school rather than by the sailing instructor himself. Lori the customer clears this up for us by telling us that even if it is a school administrator, the administrator will have many of the same characteristics of an Instructor. Since an Instructor is more clearly a single person than is Sailing School, the Sailing School card is torn up.
Hardcore Sailor 卡的位置已与 Instructor、Experienced Sailor 甚至 Charter Captain 角色卡部分重叠。该小组接下来讨论了这些角色，并了解到 Hardcore Sailor 角色的编写是为了捕捉通常确切知道自己想要哪些书的水手类型。例如，Hardcore Sailor 知道最好的航海书籍的名称。因此，她的搜索模式将与知识较少的水手，甚至是经验丰富的水手的搜索模式大不相同。Experienced Sailor 角色代表非常熟悉网站将提供的产品但可能不会自动记住最好的书名的人。
The Hardcore Sailor card has been postioned so that it partially overlaps Instructor, Experienced Sailor and even the Charter Captain role cards. The group discusses these roles next and learns that the Hardcore Sailor role was written to capture the type of sailor who typically knows exactly which books she wants. The Hardcore Sailor knows, for example, the name of the best book on navigation. Her search patterns will therefore be quite different from those of a less knowledgeable sailor, even an Experienced Sailor. The Experienced Sailor role represents people very familiar with the products the site will offer but who may not automatically recall the names of the best books.
在讨论 Charter Captain 之后，团队决定该角色与 Hardcore Sailor 基本相同，并且将卡片撕毁。
After discussing Charter Captain, the team decides that role is essentially the same as Hardcore Sailor and the card is torn up.
此时，团队决定保留新手水手、教练、铁杆水手和经验丰富的水手。他们已经处理掉了 New Sailor、Charter Captain 和航海学校。他们还没有考虑礼品买家、非航海配偶、管理员和销售副总裁。这些剩余角色卡的作者解释了他们的意图。
At this point, the team has decided to keep Novice Sailor, Instructor, Hardcore Sailor, and Experienced Sailor. They’ve disposed of New Sailor, Charter Captain, and Sailing School. And they have yet to consider Gift-Buyer, Non-Sailing Spouse, Administrator, and Sales Vice President. The authors of these remaining role cards explain their intent.
礼品买家角色代表不是水手但正在为水手购买礼物的人。Non-Sailing Spouse 角色的作者表示这是该卡片背后的意图。在对两张角色卡进行一些讨论后，团队决定将它们都撕掉并用一张用于非航海礼品买家角色的合并卡取而代之。
The Gift Buyer role represents someone who is not a sailor but who is buying a gift for someone who is. The author of the Non-Sailing Spouse role indicates that this was the intent behind that card. After some discussion about the two role cards the team decides to tear both up and replace them with a consolidated card for the Non-Sailing Gift Buyer role.
Administrator 角色的作者解释说，这个角色代表将由一个或多个管理员完成的工作，他们需要将数据加载到系统中，否则将保持系统运行。这是团队谈论的第一个代表不从网站购买商品的人的角色。在讨论之后，他们认为这个角色很重要，Lori 表示她将有一些关于如何维护系统以及如何将新项目添加到站点库存的故事。
The author of the Administrator role explains that this role represents the work that will be done by one or more administrators who will need to load data into the system and otherwise keep the system running. This is the first role the team talks about that represents someone who is not buying items from the site. After discussing it, they decide that the role is important, and Lori indicates that she will have some stories about how the system will be maintained and how new items will be added to the site’s inventory.
接下来将讨论销售副总裁的角色。这是另一个非采购角色。然而，首席执行官已下令密切关注新系统，以了解其对销售的影响。团队考虑将角色排除在外，因为他们认为不会有很多专门针对该角色的故事。在最后他们决定包含该角色，但将其重命名为更通用的 Report Viewer。
The Sales Vice President role is discussed next. This is another non-purchasing role. However, the CEO has mandated that the new system be watched very closely to see how it is affecting sales. The team considers leaving the role out because they don’t think there will be many stories specifically for the role. In the end they decide to include the role but to rename it to the more generic Report Viewer.
讨论了图书馆的角色。有那么一刻，团队认为它可能类似于帆船学校甚至非帆船配偶。然而，该小组拒绝了这些想法，并决定保留 Library 作为一个角色。但是，为了与创建代表离散用户的角色的指南保持一致，借书证被撕掉并用图书管理员卡取而代之。
The Library role is discussed. For a moment the team thinks it might be similar to either a Sailing School or even a Non-Sailing Spouse. However, the group rejects these ideas and decides to keep Library as a role. However, in keeping with the guideline to create roles that represent discrete users, the Library card is ripped up and replaced with a Librarian card.
此时团队已经确定了图 17.2中所示的角色。
At this point the team has settled on the roles shown in Figure 17.2.
图 17.2。 合并和初步讨论后的角色。
Figure 17.2. The roles after consolidation and initial discussion.
角色建模
Role Modeling
接下来，团队考虑每个角色并在角色卡中添加详细信息。详细信息将根据领域和软件类型而有所不同，但需要考虑的一般因素包括：
Next, the team considers each role and adds detail to the role cards. The details will vary based on the domain and the type of software but good, general factors to consider include:
- 用户使用软件的频率。
- The frequency with which the user will use the software.
- 用户在域中的专业水平。
- The user’s level of expertise with the domain.
- 用户对计算机和软件的一般熟练程度。
- The user’s general level of proficiency with computers and software.
- 用户对正在开发的软件的熟练程度。
- The user’s level of proficiency with the software being developed.
- 用户使用软件的总体目标。有些用户追求便利，有些则喜欢丰富的体验，等等。
- The user’s general goal for using the software. Some users are after convenience, others favor a rich experience, and so on.
该小组针对每张角色卡讨论这些问题。他们按如下方式更新用户角色卡：
The group discusses these issues for each role card. They update the user role cards as follows:
新手水手：经验丰富的网络购物者。预计在航行的前 3 个月内进行 6 次采购。有时被称为特定的头衔；其他时候需要帮助来选择合适的书。在选择合适的书籍（以适当的水平编写的好内容）方面，她希望得到比实体书店更多的帮助。
Novice Sailor: Experienced web shopper. Expected to make 6 purchases during first 3 months of sailing. Is sometimes referred to a specific title; other times needs help selecting the right book. Wants more help in selecting appropriate books (good content written at the appropriate level) than she gets in a physical bookstore.
指导员：预计会经常使用该网站，通常每周一次。通过公司的电话销售组，一位讲师经常下类似的订单（例如，同一本书的 20 份）。精通网站，但通常对计算机有些紧张。有兴趣获得最优惠的价格。对评论或其他“虚饰”不感兴趣。
Instructor: Expected to use the website frequently, often once a week. Through the company’s telephone sales group, an Instructor frequently places similar orders (for example, 20 copies of the same book). Proficient with the website but usually somewhat nervous around computers. Interested in getting the best prices. Not interested in reviews or other “frills.”
Hard Core Sailor：通常对计算机没有经验。公司目录中商品的大量购买者，但不是书籍的大量购买者。从我们这里购买了很多额外的设备。通常确切地知道他在寻找什么。不想在尝试使用该网站时感到愚蠢。
Hard Core Sailor: Generally inexperienced with computers. A large purchaser of items from the company’s catalog but not a large purchaser of books. Buys lots of additional equipment from us. Usually knows exactly what he’s looking for. Doesn’t want to feel stupid while trying to use the site.
经验丰富的水手：精通电脑。预计每季度订购一次或两次，夏季可能更频繁。了解航海知识，但通常仅限于当地地区。对其他水手所说的最好的产品和最好的航行地点非常感兴趣。
Experienced Sailor: Proficient with computers. Expected to order once or twice per quarter, perhaps more often during the summer. Knowledgeable about sailing but usually only for local regions. Very interested in what other sailors say are the best products and the best places to sail.
非航海礼品买家：通常精通电脑（或不会选择在线购买礼品）。不是水手，最多只能熟悉航海术语。通常是在寻找一本非常具体的书，但也可能是在寻找关于特定主题的书。
Non-Sailing Gift Buyer: Usually proficient with computers (or would not chose to purchase a gift online). Not a sailor and will have passing familiarity at best with sailing terms. Will usually be after a very specific book but may be looking for a book on a given topic.
图书管理员：精通电脑。确切地知道她在寻找什么，并且更喜欢按 ISBN 而不是作者甚至标题来订购。对礼品包装或跟踪发货等装饰品不特别感兴趣。通常每年会下少量订单，但每个订单所订购的书籍都比典型的单个订单多。
Librarian: Proficient with computers. Knows exactly what she is looking for and prefers to order by ISBN rather than author or even title. Not particularly interested in frills such as gift wrapping or tracking shipments. Will generally place a small number of orders per year but each order will be for more books than a typical individual order.
管理员：精通电脑。至少对航海有一定的了解。作为她工作的一部分，每天访问系统的后端。有兴趣快速学习该软件，但稍后会需要高级用户快捷方式。
Administrator: Highly proficient with computers. Has at least a passing familiarity with sailing. Accesses the back-end of the system daily as part of her job. Interested in quickly learning the software but will want advanced user shortcuts later.
报告查看者：中等水平的计算机使用能力，主要是电子表格和文字处理器等商业程序。对有关系统如何工作、访问者购买或不购买什么以及他们如何浏览或搜索网站的高度详细数据感兴趣。非常愿意用速度换取力量和深度。
Report Viewer: Moderate proficiency with computers, mostly with business programs such as spreadsheets and word processors. Interested in highly detailed data on how the system is working, what visitors are buying or not buying, and how they are navigating or searching the site. Very willing to trade speed for power and depth.
添加角色
Adding Personas
有时值得花几分钟时间为迄今为止完成的工作添加一个角色。该团队询问 Lori，这些用户角色中的哪些必须绝对满足新网站才能成功。她说，Hardcore Sailors 很重要，因为他们作为客户的寿命很长。但是，即使他们经常航行，他们也不是大量的书籍购买者。另一方面，大量有经验的水手很重要，他们购买了大量书籍。Lori 补充说，也许最重要的角色是讲师。教官全年可负责数百本书的销售。事实上，她继续说道，她想通过新网站研究最终向推荐学生访问该网站的教师提供经济奖励的方法。
It is sometimes worth spending a few minutes adding a persona to the work done thus far. The team asks Lori which of these user roles must absolutely be satisfied with the new website in order for it to succeed. She says that Hardcore Sailors are important because of their longevity as customers. But, even though they sail frequently, they are not large purchasers of books. On the other hand, the large population of Experienced Sailors is important and that group buys a significant number of books. Lori adds that perhaps the most important role to satisfy is the Instructor. Instructors can be responsible for the sale of hundreds of books throughout the year. In fact, she continues, with the new website she’d like to investigate ways of eventually offering financial incentives to Instructors who refer their students to the site.
考虑到这些信息，团队决定开发两个角色。第一个角色是特蕾莎。特蕾莎已经航行了四年。她是一家上市生物技术公司的首席执行官，对在线订购非常满意。Teresa 主要在夏季航行，因此她只会在春季或夏季为游轮做准备时使用该站点。她很忙，有兴趣使用我们的网站来节省时间并查找她以前从未看过的书籍。Teresa 嫁给了 Tom，Tom 自己不航行，但曾两次陪同 Teresa 航行穿越地中海。
With this information in mind the team decides to develop two personas. The first persona is Teresa. Teresa has been sailing for four years. She is the CEO of a publicly-traded biotech company and is completely comfortable ordering online. Teresa sails mainly during the summer so she’ll only use the site during spring or summer, when preparing for a cruise. She’s very busy and is interested in using our site to save time and to find books she hasn’t seen before. Teresa is married to Tom, who doesn’t sail himself but has accompanied Teresa on on two cruises through the Mediterranean.
第二个角色是罗恩船长。罗恩船长拥有 40 年的航海经验，并在圣地亚哥开办了一所航海学校。五年前，他从高中教师退休，此后一直担任帆船教练。十年来，他一直是目录的忠实客户。他仍然对办公室里的电脑有点害怕，但他对在网上订购非常感兴趣，我们希望他试一试。
The second persona is Captain Ron. Captain Ron has been sailing for 40 years and runs a sailing school out of San Diego. He retired from teaching high school five years ago and has been a sailing instructor ever since. He’s been a loyal catalog customer for ten years. He’s still a little intimidated by the computer in his office but he’s intrigued enough by ordering on the web that we expect him to give it a try.
关于特蕾莎和罗恩船长的警告
是否值得向该系统添加角色是值得商榷的。只有在这样做可以帮助您的团队为系统的关键满足用户思考故事时才添加角色。对于这些章节中描述的 South Coast Nautical Supplies 系统，可能不值得付出额外的努力。
It’s debatable whether it is worth adding personas to this system. Only add a persona if doing so helps your team think through stories for a critical-to-satisfy user of your system. For the South Coast Nautical Supplies system described in these chapters, it’s probably not worth the extra effort.
然而，由于角色可以成为您工具箱中的一个有价值的补充，我将 Teresa 和罗恩船长包括在内以提供更完整的示例。
However, since personas can be a valuable addition to your toolbox, I have included Teresa and Captain Ron in order to provide a more complete example.
第 18 章故事
Chapter 18. The Stories
为了生成最初的故事列表，团队决定召开一个故事写作研讨会，他们将花一两个小时尽可能多地写故事。在故事写作工作坊中，一种方法是按任意顺序编写故事，而不管故事中可能扮演的角色或人物角色。另一种方法是从特定的用户角色或角色开始，写下团队在转向下一个角色或角色之前可以想到的所有故事。两种方法的结果应该相同。在这种情况下，团队会讨论并选择处理每个角色和角色。
To generate the initial list of stories, the team decides to convene a story writing workshop where they will dedicate an hour or two to writing as many stories as they can. During a story writing workshop, one approach is to just write stories in any order regardless of which role or persona may act in the story. An alternative approach is to start with a specific user role or persona and write all the stories the team can think of before moving onto the next role or persona. The results should be the same with either approach. In this case the team discusses it and chooses to work through each role and persona.
特蕾莎的故事
Stories for Teresa
团队决定从 Teresa 开始，Teresa 是上一章中确定的人物角色，因为团队的客户成员 Lori 曾表示，新网站让 Teresa 满意至关重要。团队知道 Teresa 追求的是速度和便利。她是一个真正的超级用户，不会介意一点额外的复杂性，只要复杂性可以帮助她更快地找到她正在寻找的东西。他们写的第一个故事是18.1。
The team decides to start with Teresa, a persona identified in the previous chapter, since the team’s customer member, Lori, has said that it is critical that the new website satisfy Teresa. The team knows Teresa is looking for speed and convenience. She’s a true power user and will not mind a little extra complexity as long as the complexity helps her find what she’s looking for more quickly. The first story they write is 18.1.
故事卡 18.1。
Story Card 18.1.
开发人员对这个故事有一些疑问。例如，用户能否同时按作者、书名和 ISBN 进行搜索，或者 Lori 是否希望他们一次只按一个标准进行搜索？他们暂时搁置这些问题，专注于写下更多的初步故事。
The developers have some questions about this story. For example, can the user search by author, title and ISBN at the same time, or does Lori want them to search by only one criterion at a time? They let these questions sit for now and focus on getting more preliminary stories written down.
接下来，Lori 说，在搜索一本书后，用户可以看到关于一本书的详细信息。她举了几个例子说明她所指的信息类型，然后写下18.2。
Next, Lori says that after searching for a book a user can see detailed information about a book. She gives a few examples of the type of information she means and then writes 18.2.
故事卡 18.2。
Story Card 18.2.
除了这三个细节之外，她可能还想要更多，但开发人员可以稍后在准备好编写这个故事时询问她。
There’s probably more she’ll want besides these three details but the developers can ask her later when they’re ready to code this story.
作为一个典型的电子商务网站，该团队知道用户需要一个“购物车”，并且用户会购买他们购物车中的书籍。客户 Lori 还表示，在处理订单之前，用户需要有机会从购物车中删除图书。这导致18.3和18.4。
As a typical eCommerce site, the team knows that users will need a “shopping cart” and that users will buy the books in their shopping carts. Lori the customer also says that a user will need the chance to delete books from the shopping cart before the order is processed. This leads to 18.3 and 18.4.
故事卡 18.3。
Story Card 18.3.
故事卡 18.4。
Story Card 18.4.
要实际使用信用卡处理订单，系统需要知道要收费的信用卡和一些地址信息。这导致18.5。
To actually process an order with a credit card, the system will need to know the credit card to charge and some address information. This leads to 18.5.
故事卡 18.5。
Story Card 18.5.
Lori 提醒开发人员，由于 Teresa 才航行了四年，她并不总是知道自己想要什么书。对于 Teresa，该站点应包括供客户评价和评论项目的功能。这导致 Lori 写下18.6。
Lori reminds the developers that since Teresa has only been sailing for four years, she won’t always know exactly what book she wants. For Teresa the site should include features for customers to rate and review items. This leads Lori to write 18.6.
故事卡 18.6。
Story Card 18.6.
由于 Teresa 希望能够尽快订购，团队决定系统需要记住运输和账单信息。该网站的一些客户，例如非航行礼品买家角色，可能不会经常购买，因此这些客户可能不想创建可重复使用的帐户。同样，第一次的任何额外步骤都可能吓跑总是对新网站有点试探性的罗恩船长。因此，Lori 决定用户可以使用或不使用帐户来购买书籍，并写入18.7和18.8。
Since Teresa wants to be able to order as quickly as possible, the team decides that the system needs to remember shipping and billing information. Some of the site’s customers, for example the Non-Sailing Gift Buyer role, may not buy very often so these customers may not want to create a reusable account. Similarly, any extra steps the first time may scare off Captain Ron who is always a little tentative with new websites. So, Lori decides that a user can buy books with or without an account and writes 18.7 and 18.8.
故事卡 18.7。
Story Card 18.7.
故事卡 18.8。
Story Card 18.8.
该团队还知道 Teresa 想要将物品放入她想要但今天还没有准备好购买的物品的愿望清单中。她要么稍后自己购买，要么告诉她的丈夫汤姆，他会从她的愿望清单中购买。所以，Lori 写了18.9和18.10。
The team also knows that Teresa wants to put items on a wish list of items she wants but is not ready to buy today. She’ll either buy them for herself later or she’ll tell her husband, Tom, and he’ll buy items from her wish list. So, Lori writes 18.9 and 18.10.
故事卡 18.9。
Story Card 18.9.
故事卡 18.10。
Story Card 18.10.
我们希望确保任何编写 18.10程序的人都知道用户可以从她自己或其他人的愿望清单中选择项目。我们一定要在卡片上注明这一点（在这种情况下用括号括起来）。
We want to make sure that whoever programs 18.10 knows that a user can select items from her own or someone else’s wish list. We make sure to note that on the card (parenthetically in this case).
由于速度对 Teresa 很重要，Lori 还确定了与订购一本书所需时间相关的性能限制。她写道18.11。
Because speed will be important to Teresa, Lori also identifies a performance constraint relating to how long it takes to order a book. She writes 18.11.
故事卡 18.11。
Story Card 18.11.
在这种情况下，Lori 选择关注回头客搜索图书和完成订单所需的时间。这是一个很好的性能要求，因为它捕获了用户对站点体验的所有方面。如果用户界面的导航非常混乱，以至于用户需要三分钟才能到达搜索屏幕，那么再快的数据库查询和中间件也无济于事。这个故事比“搜索必须在两秒钟内完成”这样的故事更好地反映了这一点。当然，Lori 可以添加更多的性能约束，但通常像这个故事那样选择几个广泛的约束就足够了。
In this case Lori has chosen to focus on the time it takes a repeat customer to search for a book and complete her order. This is a good performance requirement because it captures all aspects of the user’s experience with the site. Blazing fast database queries and middleware don’t count for much if the user interface is so confusing to navigate that it takes a user three minutes to get to the search screen. This story reflects this better than would a story like “Searches must complete in two seconds.” Naturally, Lori can add more performance constraints but it is usually sufficient to pick a few broad ones like this story.
罗恩船长的故事
Stories for Captain Ron
很明显，该团队已经没有经验丰富的水手特蕾莎的故事了。因此，他们同意将注意力转移到罗恩船长身上，罗恩船长经营一所航海学校，并且对计算机的了解比特蕾莎要多一些。当队长罗恩来到他通常确切地知道自己在寻找什么的网站。这导致 Lori 写下18.12和18.13。
It becomes clear that the team is running out of stories for Teresa, the Experienced Sailor. So, they agree to switch focus to Captain Ron, who runs a sailing school and is a little more tentative with computers than is Teresa. When Captain Ron comes to the site he typically knows exactly what he’s looking for. This leads Lori to write 18.12 and 18.13.
故事卡 18.12。
Story Card 18.12.
故事卡 18.13。
Story Card 18.13.
这些故事将使罗恩船长能够回顾他的旧订单并从这些订单中重新购买物品。然而，Lori 指出罗恩船长可能还想购买他最近看过的物品，即使他之前没有购买过。她写道18.14。
These stories will allow Captain Ron to look back at his old orders and repurchase items from those orders. However, Lori points out that Captain Ron may also want to purchase an item that he looked at recently, even if he hasn’t previously purchased it. She writes 18.14.
故事卡 18.14。
Story Card 18.14.
新手水手的故事
Stories for a Novice Sailor
接下来，团队继续考虑新手水手角色。新手水手的需求在很大程度上与特蕾莎和罗恩船长的需求重叠。但 Lori 认为，如果新手水手可以看到我们的建议列表，那将会很有帮助。在这里，新手水手可以找到我们推荐的关于各种主题的书籍。她写道18.15。
Next, the team moves on to consider the Novice Sailor role. The needs of a Novice Sailor largely overlap those of Teresa and Captain Ron. But Lori decides it would be helpful if a Novice Sailor could see a list of our recommendations. Here the Novice Sailor could find the books we recommend on a variety of topics. She writes 18.15.
故事卡 18.15。
Story Card 18.15.
非航海礼品买家的故事
Stories for a Non-Sailing Gift Buyer
切换到非航行礼品买家的角色，团队讨论了购物者如何能够轻松找到另一个人的愿望清单。他们开始讨论各种设计解决方案以及将使用哪些字段进行搜索，直到他们记起设计讨论应该留待以后使用。Lori 没有在这次会议上设计功能，而是编写了18.16。
Switching to the Non-Sailing Gift Buyer role, the team discusses how it must be easy for a shopper to find the wish list of another person. They start to discuss various design solutions and what fields will be used for searching until they remember that design discussions should be saved for later. Instead of designing the feature in this meeting, Lori writes 18.16.
故事卡 18.16。
Story Card 18.16.
Lori 还知道系统需要支持礼品卡和包装。她写道18.17和18.18。
Lori also knows that the system needs to support gift cards and wrapping. She writes 18.17 and 18.18.
故事卡 18.17。
Story Card 18.17.
故事卡 18.18。
Story Card 18.18.
报告查看者的故事
Stories for a Report Viewer
Lori 说系统需要生成有关购买和流量模式等的报告。她还没有详细考虑报告，因此开发人员编写了一个简单的占位故事，提醒他们有报告需要开发。他们稍后会决定报告的内容。现在她写18.19。
Lori says that the system needs to generate reports on purchase and traffic patterns and so on. She hasn’t yet thought about the reports in detail so the developers write a simple placeholding story that will remind them that there are reports to develop. They’ll decide on the report contents later. For now she writes 18.19.
故事卡 18.19。
Story Card 18.19.
一想到报告，洛瑞就想起报告是高度敏感的。自然地，他们不会从消费者看到的主站点上获得。但是，她说只有公司内的某些人可以访问报道。这可能意味着如果您可以访问一个报告，那么您就可以访问所有报告，或者这可能意味着某些用户只能访问某些报告。开发人员现在不问 Lori 了，Lori 写了18.20。
Thinking about reports reminds Lori that the reports are highly sensitive. Naturally, they won’t be available from the main site that consumers see. But, she says that only certain people within the company can have access to the reports. This could mean that if you can access one report you can access them all, or it could mean some users can access only some reports. The developers don’t ask Lori about that now and Lori writes 18.20.
故事卡 18.20。
Story Card 18.20.
为了使报告有意义，Lori 说网站使用的数据库必须与我们当前基于电话的系统使用的数据库相同。这导致 Lori 编写了18.21中显示的约束。
To make reports meaningful, Lori says that the database used by the website must be the same database used by our current telephone-based system. This leads Lori to write the constraint shown on 18.21.
故事卡 18.21。
Story Card 18.21.
一些行政故事
Some Administration Stories
此时注意力转移到管理员用户角色。该团队立即想到18.22和18.23。
At this point attention shifts to the Administrator user role. The team thinks instantly of 18.22 and 18.23.
故事卡 18.22。
Story Card 18.22.
添加新书的故事提醒他们，管理员需要删除书籍并编辑书籍，以防添加书籍时使用了错误的信息。所以他们写18.24和18.25。
The story about adding new books reminds them that administrators need to delete books and also edit books in case incorrect information was used when the book was added. So they write 18.24 and 18.25.
故事卡 18.24。
Story Card 18.24.
故事卡 18.25。
Story Card 18.25.
包起来
Wrapping Up
到现在为止，Lori 的故事已经开始用完了。到目前为止，每个故事都立即浮现在脑海中，但现在她不得不考虑是否还有其他故事。因为该项目将使用增量和迭代开发过程来完成，所以她预先考虑每个故事并不重要。但是因为她想要初步估计系统构建需要多长时间，团队确实希望在不花费过多时间的情况下尽可能多地考虑。如果 Lori 在我们开始后想出一个新故事，她将有机会把它移到发行版中，前提是她移出大约相同数量的工作。
By now Lori is starting to run out of stories. So far, each story has come instantly to mind but now she’s having to think about whether there are any others. Because the project will be done using an incremental and iterative development process, it’s not important that she think of every story right up front. But because she wants a preliminary estimate of how long the system will take to build, the team does want to think of as much as they can without spending an inordinate amount of time. If Lori comes up with a new story once we’ve started, she’ll have the opportunity to move it into the release if she moves out the same approximate amount of work.
开发人员询问 Lori 到目前为止是否还有其他她认为已经忘记的故事。她写道18.26。
The developers ask Lori if there are any other stories she feels have been forgotten thus far. She writes 18.26.
故事卡 18.26。
Story Card 18.26.
Lori 还提醒开发人员，可扩展性需求并不大，但站点确实需要处理至少 50 个并发用户。他们在18.27上写了这个约束。
Lori also reminds the developers that scalability needs are not tremendous but that the site does need to handle at least 50 concurrent users. They write this constraint on 18.27.
第 19 章估计故事
Chapter 19. Estimating the Stories
故事写作研讨会产生了 27 个故事，总结在表 19.1中。下一个目标是制定一个发布计划，向客户 Lori 展示开发人员期望完成的工作以及网站是否可以在老板规定的 30 天期限内投入运营。因为在这 30 天内可能无法完成更多的工作，所以开发人员需要与 Lori 密切合作来确定故事的优先级。
The story writing workshop resulted in 27 stories, which are summarized in Table 19.1. The next goal is to create a release plan that will show Lori the customer what the developers expect to accomplish and whether the site can be operational within the boss’s thirty day deadline. Because there is probably more work than can be completed in those thirty days, the developers will need to work closely with Lori to prioritize stories.
表 19.1。 最初的故事集。
Table 19.1. The initial collection of stories.
为了创建发布计划，需要对每个故事进行估算。正如我们在第 8 章“估算用户故事”中了解到的那样，开发人员将以代表理想时间、复杂性或对团队有意义的其他度量的故事点来估算每个故事。
In order to create the release plan an estimate is needed for each story. As we learned in Chapter 8, “Estimating User Stories,” the developers are going to estimate each story in story points that represent ideal time, complexity, or some other measure meaningful to the team.
第一个故事
The First Story
不必从列表中的第一个故事开始（“用户可以按作者、书名或 ISBN 编号搜索书籍”），但在这种情况下，第一个故事是一个很好的开始估算的故事。当 Lori 写这个故事时，开发人员不确定 Lori 的意思是用户可以同时搜索所有这些字段，还是用户一次只能搜索一个字段。由于 Lori 的回答可能会对估算产生重大影响，因此值得询问她。
It isn’t necessary to start with the first story in this list (“A user can search for books by author, title or ISBN number”) but in this case the first story is a good one to start estimating with. When Lori wrote this story, the developers weren’t sure if Lori meant that a user could search for all of these fields at the same time or whether a user could search only one at a time. Since Lori’s answer could have a big impact on the estimate, it’s worth asking her.
洛瑞自然会说她两者都想要。她想要一种基本的搜索模式，其中一个字段中的值可以同时搜索作者和标题。然后她想要一个高级搜索屏幕，其中可以组合使用任何或所有这些字段。即使有两种搜索模式，故事也没有那么大；但是模式之间的划分如此简单，以至于每个人都同意撕毁故事并用19.1和19.2代替。
Naturally Lori says she wants both. She wants a basic search mode where the value in one field searches both author and title. She then wants an advanced search screen where any or all of these fields can be used in combination. Even with both search modes the story isn’t that big; but there’s such an easy division between the modes that everyone agrees to tear up the story and replace it with 19.1 and 19.2.
故事卡 19.1。
Story Card 19.1.
故事卡 19.2。
Story Card 19.2.
为了估计这些故事，三个程序员——Rafe、Jay 和 Maria——与客户 Lori 一起在一个房间里。他们带来了故事卡片和几十张空白卡片。程序员谈论19.1，通过向 Lori 提问来澄清一些细节，然后每个程序员在索引卡上写下他或她的估计。每个人都完成后，每个程序员都会举起自己的卡片，让每个人都能看到。他们写道：
To estimate the stories, three programmers—Rafe, Jay and Maria—get together in a room with Lori, the customer. They bring along the story cards and a few dozen blank cards. The programmers talk about 19.1, clarify a few details on it by asking questions of Lori, and then each programmer writes his or her estimate on an index card. When everyone is done, each programmer holds his or her card up so everyone can see it. They’ve written:
雷夫：1
Rafe: 1
周杰伦：½
Jay: ½
玛丽亚：2
Maria: 2
这三位开发人员讨论了他们的估计。玛丽亚解释了为什么她认为这个故事值得两个故事点。她谈到他们需要如何选择一个搜索引擎，将其合并，然后才能编写屏幕来完成这个故事。Jay 说他已经熟悉所有可能的搜索选项并且对他们应该去的方向非常有信心，这就是为什么他的估计要低得多。
These three developers discuss their estimates. Maria explains why she thinks this story is worth two story points. She talks about how they’ll need to select a search engine, incorporate it, and only then be able to write the screens to fulfill the story. Jay says that he’s already familiar with all likely searching options and is pretty confident about the direction they should go, which is why his estimate is so much lower.
每个人都被要求写下一个新的估计。当他们失败时，他们会再次亮出自己的牌。这次卡片上写着：
Everyone is asked to write down a new estimate. When they’re down they again show their cards. This time the cards say:
雷夫：1
Rafe: 1
周杰伦：1
Jay: 1
玛丽亚：1
Maria: 1
那很容易。Jay 决定提高他的估计，而 Maria 相信他们可以比她原先想象的更快地完成这个故事。他们现在有一个单层点估计用于19.1。他们开始写下估计值，如表 19.2所示。
That was pretty easy. Jay decided to move his estimate up and Maria was convinced that they could do the story faster than she originally thought. They now have a one-story point estimate to use for 19.1. They start writing estimates down as shown in Table 19.2.
表 19.2。 开始写下估计。
Table 19.2. Starting to write down the estimates.
请注意，当程序员提出这些估计时，客户 Lori 在场，但她并没有通过写下她的估计来参与。由于 Lori 不是该项目的程序员，因此不允许她进行估算。此外，她不得在估计时喘息或以其他方式表达震惊。如果她这样做，她将破坏估算工作。当然，如果 Lori 听到的估算值听起来不合时宜（太高或太低），她可能需要提供一些指导或说明。例如，她可能会提供类似这样的内容：“我可以理解你所描述的十个故事点，但我想我要求的东西要简单得多。我真正想要的只是……”
Note that Lori the customer is present while the programmers come up with these estimates but she isn’t participating by writing down her estimates. Since Lori isn’t a programmer on the project, she isn’t allowed to estimate. Further, she’s not allowed to gasp or otherwise express shock at an estimate. If she does, she’ll undermine the estimation effort. Of course, if Lori hears an estimate that sounds way out of line (either too high or too low) she may need to provide some guidance or clarification. For example, she may offer something along the lines of “I can see how that might be ten story points as you’re describing it but I think I’m asking for something much, much simpler. All I really want is …”
高级搜索
Advanced Search
在19.2上，高级搜索。程序员再次将他们的估计写在索引卡上，同时将它们翻过来显示：
On to 19.2, the advanced search. The programmers again write their estimates on index cards and turn them over at the same time showing:
雷夫：2
Rafe: 2
周杰伦：1
Jay: 1
玛丽亚：2
Maria: 2
Rafe 说高级搜索将比基本搜索花费更长的时间，因为要搜索的内容更多。Jay 表示同意，但表示由于基本搜索已经编码，添加高级搜索功能不会花很长时间。然而，Maria 指出这些故事是独立的，我们不知道哪个故事会先完成。顾客 Lori 说她不确定要先完成哪个。她倾向于先进行基本搜索，但在知道每个搜索的估计值（即成本）之前她不会确定。
Rafe says the advanced search will take a little longer than the basic search because there’s more to search on. Jay agrees but says that since the basic search will have already been coded, it won’t take long to add the advanced search features. However, Maria points out that the stories are independent and we don’t know which story will be done first. Lori the customer says she’s not sure which she’ll want done first. She’s inclined to have the basic search done first but won’t be sure until she knows the estimate (that is, cost) of each.
在卡片上又写了一两轮估算后，每个人都同意，虽然高级搜索比基本搜索要多做一些工作，但并不多，他们应该再次使用一个故事点的估算。
After another round or two of writing estimates on cards, everyone agrees that while there is a bit more work on the advanced search than the basic search, it isn’t much and they should again use an estimate of one story point.
接下来的几个故事很容易估计，不需要拆分。开发人员得出表 19.3中所示的估计值。
The next few stories are straightforward to estimate and none need to be split. The developers arrive at the estimates shown in Table 19.3.
表 19.3。 建立估计清单。
Table 19.3. Building up the list of estimates.
评级和审查
Rating and Reviewing
下一个故事（“用户可以对书籍进行评分和评论”）有点难。在写下估算值并将它们展示给彼此之前，开发人员会谈论这个故事。评级部分似乎并不难，但评论似乎更复杂。他们需要一个屏幕供用户输入评论并可能进行预览。评论只是纯文本还是评论者可以输入 HTML？用户只能评论从我们这里购买的图书吗？
The next story (“A user can rate and review books”) is a bit harder. Before writing down estimates and showing them to each other, the developers talk about this story. The rating part doesn’t seem hard but the reviews seem more complicated. They’ll need a screen for users to enter a review and maybe to preview it. Will reviews just be plain text or can the reviewer type in HTML? Can users only review books they bought from us?
因为评论比仅仅对书籍进行评级涉及更多，所以我们决定拆分这个故事。这导致19.3和19.4。程序员将19.3估计为两个故事点，将19.4估计为四个故事点。
Because reviews are so much more involved than just rating books, we decide to split the story. This leads to 19.3 and 19.4. The programmers estimate 19.3 as two points and 19.4 as four story points.
故事卡 19.3。
Story Card 19.3.
在考虑对书籍进行评级和评论时，他们还会考虑“管理员需要在评论上架之前批准或拒绝评论”。这可能非常简单，也可能涉及更多，并要求管理员确定她拒绝评论的原因，或者可能给评论者发电子邮件。程序员认为 Lori 不会想要任何复杂的东西，他们的讨论导致对两个故事点的估计。
While they’re thinking about rating and reviewing books, they also consider “An administrator needs to approve or reject reviews before they’re available on the site.” This could be really simple, or it could be more involved and require the administrator to identify the reason she rejects a review or possibly email the reviewer. The programmers don’t think Lori will want anything complicated and their discussion leads to an estimate of two story points.
帐户
Accounts
下一个故事（“用户可以建立一个记住运输和账单信息的帐户”）似乎很简单，开发人员估计它有两个故事点。
The next story (“A user can establish an account that remembers shipping and billing information”) seems straightforward and the developers estimate it at two story points.
接下来，开发人员开始估计“用户可以编辑她的帐户信息（信用卡、送货地址、账单地址等）”。这个故事不是很大，但很容易拆分。像这样拆分一个故事通常是一个好主意，因为它在发布计划期间提供了更大的灵活性，并且允许客户在更精细的级别上确定工作的优先级。例如，在我们的案例中，Lori 可能认为用户编辑他们的信用卡很重要，但她可能愿意等待几次迭代，让用户能够更改地址。原始故事被拆分，导致19.5和19.6。这些故事似乎都不难，因此程序员估计19.5为 ½ 故事点，19.6为 1 点。
Next, the developers start to estimate “A user can edit her account information (credit card, shipping address, billing address and so on).” This story is not very large but it is easily split. Splitting a story like this one is frequently a good idea because it allows more flexibility during release planning and it allows the customer to prioritize work at a much finer level. In our case, for example, Lori may think it is critical for users to edit their credit cards but she may be willing to wait a few iterations for the ability for users to change addresses. The original story is split, resulting in 19.5 and 19.6. Neither of these stories seems difficult so the programmers estimate 19.5 as ½ story point and 19.6 as one point.
故事卡 19.5。
Story Card 19.5.
故事卡 19.6。
Story Card 19.6.
完成估算
Finishing the Estimates
对每个剩余的故事重复相同的过程。剩下的故事中只有少数值得特别提及。首先是模糊的故事：“一个用户，尤其是非航海礼品买家，可以很容易地找到其他用户的愿望清单。” 当被问及她对用户如何搜索愿望清单的意图时，Lori 提供了足够的细节，故事可以改写为19.7。
This same process is repeated for each of the remaining stories. Only a few of the remaining stories are worth specific mention. First is the vague story: “A user, especially a Non-Sailing Gift Buyer, can easily find the wish lists of other users.” When asked about her intentions regarding how users could search for a wish list, Lori provides enough detail that the story can be rewritten as 19.7.
故事卡 19.7。
Story Card 19.7.
接下来，大家同意拆分“用户可以查看她最近订单的状态。如果订单未发货，她可以添加或删除书籍、更改送货方式、送货地址和信用卡。” 一个故事将涵盖检查最近订单的状态；第二个故事涉及更改尚未发货的订单。故事显示在19.8和19.9上。
Next, everyone agrees to split “A user can check the status of her recent orders. If an order hasn’t shipped, she can add or remove books, change the shipping method, the delivery address and the credit card.” One story will cover checking the status of a recent order; the second story covers changing orders that haven’t yet shipped. The stories are shown on 19.8 and 19.9.
故事卡 19.8。
Story Card 19.8.
故事卡 19.9。
Story Card 19.9.
最后，这三个故事是约束条件：
Finally, these three stories are constraints:
- 回头客必须能够在 90 秒内找到一本书并完成订单。
- A repeat customer must be able to find one book and complete an order in less than 90 seconds.
- 网站上的订单最终必须与电话订单在同一个订单数据库中。
- Orders made on the website have to end up in the same order database as telephone orders.
- 系统必须支持最多 50 个并发用户的峰值使用。
- The system must support peak usage of up to 50 concurrent users.
作为约束，它们会影响其他故事，但它们本身不需要任何特定的编码。
As constraints they influence other stories but do not require any specific coding themselves.
所有的估计
All the Estimates
表 19.4显示了所有的估计。
Table 19.4 shows all of the estimates.
表 19.4。 故事和估计的完整列表。
Table 19.4. The complete list of stories and estimates.
第 20 章发布计划
Chapter 20. The Release Plan
为了创建发布计划，必须执行以下步骤：
The following steps are necessary in order to create the release plan:
1. 选择迭代长度。
1. Select an iteration length.
2. 估计速度。
2. Estimate the velocity.
3. 优先考虑故事。
3. Prioritize the stories.
4. 将故事分配给一个或多个迭代。
4. Allocate stories to the one or more iterations.
因为新的网站功能需要在四个星期内可用，所以团队决定使用两周的迭代。这将使他们有机会在截止日期前运行两次迭代。他们会将优先级最高的功能优先放入第一次迭代中，以确保完成这些功能。在第一次迭代之后，他们将能够评估他们的速度并决定他们可以为第二次迭代带来多少工作量。
Because the new website features need to be available in four weeks, the team decides to use two-week iterations. This will give them the opportunity to run two iterations before the deadline. They’ll prioritize the highest priority features into the first iteration to make sure those are completed. After the first iteration they will be able to assess their velocity and decide how much work they can bring into the second iteration.
估计速度
Estimating Velocity
Maria 和 Rafe 将是该项目的程序员。Jay 帮助估算，但其他承诺阻止他帮助开发网站。由于该项目不同于程序员开发的先前网站，因此他们无法根据先前项目的速度来估算新项目的速度。因此，他们需要进行有根据的猜测。
Maria and Rafe are will be the programmers on the project. Jay helped estimate but other commitments prevent him from helping develop the website. Since the project is unlike prior websites that the programmers have developed, they cannot estimate a velocity for the new project by basing it on the velocity of a prior project. So, they’ll need to take an educated guess.
在估算故事时，Maria 和 Rafe 将一个故事点粗略地定义为一个理想的编程日。他们现在决定，他们将花费两到三天的实际时间来完成一天理想的工作。对于两周（十天）的迭代和两名程序员，每次迭代将有二十个程序员日。Maria 和 Rafe 估计他们将能够在每次迭代期间完成 7 到 10 个故事点。决定对第一次迭代保守一些，他们估计速度为 8。
When they estimated the stories, Maria and Rafe loosely defined one story point as one ideal day of programming. They now decide that it will take them between two and three real days to do one ideal day worth of work. With two-week (ten-day) iterations and two programmers, there will be twenty programmer-days per iteration. Maria and Rafe estimate that they’ll be able to complete between seven and ten story points during each iteration. Deciding to be conservative for the first iteration, they estimate velocity at eight.
优先考虑故事
Prioritizing the Stories
Lori 客户优先考虑故事。决定故事优先级的主要因素是它将为企业带来的价值。不过，洛瑞还需要考虑对故事的估价。有时，当考虑成本（估计值）时，非常受欢迎的故事会变得不那么受欢迎。
Lori the customer prioritizes the stories. The main factor in determining the priority of a story is the value it will deliver to the business. However, Lori also needs to consider the estimate for the story. Occasionally, highly desired stories become less desirable when their cost (the estimates) are considered.
为了开始确定优先级，Lori 根据故事卡对 4 周内目标上线日期的重要性将故事卡分成四堆：必须有、应该有、可能有和不会。Lori 的必备故事如表 20.1所示。
To start prioritizing, Lori sorts the story cards into four piles based on their importance to the targeted go-live date in four weeks: Must Have, Should Have, Could Have, and Won’t Have. Lori’s Must-Have stories are shown in Table 20.1.
表 20.1。 四个星期内首次发布的必备故事。
Table 20.1. The Must-Have stories for the initial release in four weeks.
洛瑞必备故事的估计总和为九。由于速度估计为每次迭代 8 次，并且将有两次迭代，这为深入探讨 Lori 的一些本应有的故事留下了空间。Lori从她应该拥有的故事堆中提取表 20.2中显示的故事。在她必须拥有和应该拥有的故事之间，她现在确定了 15½ 分，这足以接近程序员认为他们可以在两次迭代中完成的十六个要点。
The sum of the estimates for Lori’s must-have stories is nine. Since velocity is estimated at eight per iteration and there will be two iterations, this leaves room to dip into some of Lori’s should-have stories. Lori pulls the stories shown in Table 20.2 from her pile of should-have stories. Between her must-have and should-have stories she’s now identified 15½ points, which is close enough to the sixteen points the programmers think they can complete over two iterations.
表 20.2。 应该有的故事 Lori 添加到发布计划中。
Table 20.2. The Should-Have stories Lori adds to the release plan.
成品发布计划
The Finished Release Plan
完成的发布计划如表 20.3所示放在一起，并以这种方式传达给组织的其余部分。Maria 和 Rafe 将尽最大努力完成第一次迭代计划的工作。如果他们做得好，他们将与 Lori 合作将一两个新故事移到第一次迭代中。如果他们落后了，他们将与 Lori 合作，将一两个故事从第一次迭代转移到第二次迭代。
The finished release plan is put together as shown in Table 20.3 and is communicated to the rest of the organization that way. Maria and Rafe will do their best to complete the work planned for the first iteration. If they do well, they’ll work with Lori to move a new story or two up into the first iteration. If they get behind, they’ll work with Lori to move a story or two from the first iteration to the second.
表 20.3。 完成的发布计划。
Table 20.3. The finished release plan.
第 21 章验收测试
Chapter 21. The Acceptance Tests
故事的验收测试用于确定故事是否已完成到客户可以接受软件的该部分为完整的程度。这意味着客户负责指定测试。不过，通常情况下，客户会从分配给该项目的测试人员那里得到一些帮助。由于这个项目很小而且没有专门的测试人员，Lori 寻求 Maria 和 Rafe 的帮助。这样做的另一个好处是，除了生成验收测试列表之外，它还可以促进 Lori 和程序员之间的进一步对话。
The acceptance tests for a story are used to determine whether the story is completed to the point where the customer can accept that part of the software as complete. This means that the customer is responsible for specifying the tests. Often, though, the customer will have some help from a tester who is assigned to the project. Since this project is small and without a dedicated tester, Lori enlists the help of Maria and Rafe. An additional benefit of this is that, beyond generating a list of acceptance tests, it leads to further conversations between Lori and the programmers.
搜索测试
The Search Tests
Lori 在第一个版本中优先考虑的搜索功能显示在21.1和21.2中。21.1的测试是：
The search features that Lori prioritized into the first release are shown in 21.1 and 21.2. The tests for 21.1 are:
- 搜索一个已知是标题的一部分但不太可能是作者的词；例如，“导航”。
- Search for a word that is known to be part of a title but unlikely to be an author; for example, “navigation.”
- 搜索一个可能是作者但不太可能是标题的词；例如，“约翰”。
- Search for a word that is likely to be an author but unlikely to be a title; for example, “John.”
- 搜索一个不太可能出现在其中的词；例如，“wookie”。
- Search for a word that is unlikely to be in either; for example, “wookie.”
故事卡 21.1。
Story Card 21.1.
21.2的测试是：
The tests for 21.2 are:
- 使用至少与一本书匹配的作者和标题值。
- Use values for author and title that match at least one book.
- 使用不匹配书籍的作者和标题值。
- Use values for author and title that match no books.
- 尝试 ISBN 搜索。
- Try an ISBN search.
故事卡 21.2。
Story Card 21.2.
购物车测试
Shopping Cart Tests
21.3 and 21.4 cover the use of the shopping cart.
故事卡 21.3。
Story Card 21.3.
故事卡 21.4。
Story Card 21.4.
Lori 和程序员谈论这些故事并意识到他们有几个悬而未决的问题：用户可以将缺货的书放入购物车吗？还没有出版的书呢？此外，团队意识到21.4涵盖了将项目数量更改为 0，但没有明确的增加项目数量的故事。他们可以将其写成一个单独的故事，但决定撕掉21.4并用21.5代替。
Lori and the programmers talk about these stories and realize they have a few open questions: Can users put out-of-stock books into shopping carts? What about books that are not yet in print? Additionally, the team realizes that 21.4 covers changing the quantity of an item to 0, but there is no explicit story for increasing the quantity of an item. They could write this as a separate story but decide instead to rip up 21.4 and replaces it with 21.5.
故事卡 21.5。
Story Card 21.5.
这次讨论的一个重要结果是系统得到了简化。通过决定他们不需要一个单独的故事来从购物车中删除一个项目，该团队既提高了系统的可用性，又避免了潜在的未来工作。
An important result of this discussion is that the system has been simplified. By deciding they do not need a separate story deleting an item from a shopping cart the team has both improved the usabilility of the system and avoided potential future work.
21.3的测试是：
The tests for 21.3 are:
- 将缺货的书放入购物车。确认用户被告知该书将在可用时发货。
- Put an out-of-stock book into the cart. Verify that the user is told that the book will be shipped when it becomes available.
- 将一本尚未出版的书放入购物车。确认用户被告知该书将在可用时发货。
- Put a book that hasn’t been published yet into the cart. Verify that the user is told that the book will ship when available.
- 将有库存的书放入购物车。
- Put a book that is in stock into the cart.
- 将第二本书放入购物车。验证计数是否上升。
- Put a second copy of a book into the cart. Verify that the count goes up.
21.5的测试是
The tests for 21.5 are
- 将一本书的数量从一本更改为十本。
- Change the quantity of a book from one to ten.
- 将数量从十改为一。
- Change the quantity from ten to one.
- 通过将数量更改为零来移除一本书。
- Remove a book by changing the quantity to zero.
买书
Buying Books
21.6涵盖书籍的实际采购。在讨论这个故事时，程序员与客户 Lori 澄清了几个方面。Lori 希望用户能够输入单独的送货地址和账单地址，或者指明地址是相同的。该网站将仅接受 Visa 和 MasterCard。
21.6 covers the actual purchasing of books. In discussing this story, the programmers clarify a few aspects of it with Lori the customer. Lori wants users to be able to enter separate shipping and billing addresses or indicate that the addresses are the same. The site will accept only Visa and MasterCard.
故事卡 21.6。
Story Card 21.6.
21.6的测试是：
The tests for 21.6 are:
- 输入帐单地址并指明送货地址相同。
- Enter a billing address and indicate that the shipping address is the same.
- 输入单独的账单地址和送货地址。
- Enter separate billing and shipping addresses.
- 使用一个州和另一个州的邮政编码进行测试，并验证是否发现了不一致。
- Test with a state and a postal code that is from another state and verify the inconsistency is caught.
- 验证书籍将运送到的地址是送货地址，而不是账单地址。
- Verify that the address the books will ship to is the shipping address, not the billing address.
- 使用有效的 Visa 卡进行测试。
- Test with a valid Visa card.
- 使用有效的万事达卡进行测试。
- Test with a valid MasterCard.
- 使用有效的美国运通卡进行测试（失败）。
- Test with a valid American Express card (fail).
- 使用过期的签证进行测试。
- Test with an expired Visa.
- 使用超过信用额度的万事达卡进行测试。
- Test with a MasterCard that is over its credit limit.
- 使用缺少数字的 Visa 进行测试。
- Test with a Visa that is missing digits.
- 使用带有转置数字的 Visa 进行测试。
- Test with a Visa with transposed digts.
- 用一个号码完全无效的 Visa 进行测试。
- Test with a Visa with a completely invalid number.
用户帐户
User Accounts
21.7涵盖用户帐户的创建。这张卡的测试是：
21.7 covers the creation of user accounts. Tests for this card are:
- 用户无需创建帐户即可订购。
- Users can order without creating an account.
- 创建一个帐户然后调用它并查看信息是否已保存。
- Create an account then recall it and see if the information has been saved.
故事卡 21.7。
Story Card 21.7.
21.8和21.9允许用户修改存储在其帐户中的信息。21.8的测试是：
21.8 and 21.9 allow users to modify the information stored in their accounts. Tests for 21.8 are:
- 编辑卡号使其无效。确认用户已收到警告。
- Edit the card number to make it an invalid number. Verify that the user is warned.
- 将过期日期编辑为过去的日期。确认更改未保存。
- Edit the expiration date to one in the past. Verify that the change isn’t saved.
- 将信用卡号更改为新的有效号码，并确保更改已保存。
- Change the credit card number to a new valid number and make sure the change is saved.
- 将到期日期更改为将来的某个日期，并确保保存更改。
- Change the expiration date to a date in the future and make sure the change is saved.
故事卡 21.8。
Story Card 21.8.
21.9的测试是
Test for 21.9 are
- 更改送货地址的各个部分并验证更改是否已保存。
- Change various parts of the shipping address and verify that the changes are saved.
- 更改账单地址的各个部分并验证更改是否已保存。
- Change various parts of the billing address and verify that the changes are saved.
故事卡 21.9。
Story Card 21.9.
行政
Administration
21.10允许管理员向站点添加新书。这个故事的测试是：
21.10 allows an administrator to add new books to the site. Tests for this story are:
- 测试管理员是否可以向站点添加一本书。
- Test that an administrator can add a book to the site.
- 测试非管理员不能添加图书。
- Test that a non-administrator cannot add a book.
- 测试只有在存在所需数据时才能添加书籍。
- Test that a book can only be added if required data is present.
21.11允许管理员删除一本书。这个故事的测试是：
21.11 allows an administrator to delete a book. Tests for this story are:
- 验证管理员是否可以删除一本书。
- Verify that an administrator can delete a book.
- 验证非管理员不能删除一本书。
- Verify that a non-administrator cannot delete a book.
- 删除一本书，然后验证该书的未结订单是否仍会发货。
- Delete a book and then verify that outstanding orders for the book will still ship.
故事卡 21.11。
Story Card 21.11.
21.12允许管理员更改有关书籍的信息。当程序员和 Lori 讨论21.12时，他们讨论了如何处理未发货的订单，这些订单包括价格发生变化的书籍。这成为故事的考验之一：
21.12 allows an administrator to change information about a book. When the programmers and Lori discuss 21.12 they discuss how to handle unshipped orders that include a book for which the price changes. This becomes one of the tests for the story:
- 验证名称、作者、页数等项目。可以改变。
- Verify that items like name, author, number of pages, and so on,. can be changed.
- 确认价格可以更改，但价格更改不会影响之前下的订单（但未开票和未发货的订单）。
- Verify that price can be changed but that price changes do not affect previously placed (but unbilled and unshipped orders).
故事卡 21.12。
Story Card 21.12.
测试约束
Testing the Constraints
在 Lori 优先发布的故事中，有两个约束，分别显示为21.13和21.14。
Among the stories Lori has prioritized into the release there are two constraints, which are shown as 21.13 and 21.14.
故事卡 21.14。
Story Card 21.14.
21.13的唯一测试是检查数据库并验证从网站提交的订单是否存储在数据库中：
The only test for 21.13 is to examine the database and verify that an order submitted from the website gets stored in the database:
- 下订单。打开电话订单输入数据库并验证订单是否存储在该数据库中。
- Place an order. Open up the telephone order entry database and verify that the order was stored in that database.
Lori 拿下21.14，翻开故事卡并写道：
Lori takes 21.14, turns over the story card and writes:
- 测试五十个模拟用户进行各种搜索和下订单。确保没有任何屏幕显示时间超过四秒，并且没有订单丢失。
- Test with fifty simulated users doing a variety of searches and placing orders. Ensure that no screen takes more than four seconds to display and that no orders are lost.
最后的故事
A Final Story
唯一剩下的故事显示在21月 15 日。
The only story left is shown on 21.15.
故事卡 21.15。
Story Card 21.15.
Lori 和开发人员讨论了21.15，并决定将其作为一个简单的静态页面，其中包含针对各种主题的推荐列表。他们编写了这些测试：
Lori and the developers talk about 21.15 and decide it will be a simple static page that includes a list of recommendations for a variety of topics. They write these tests:
第五部分：附录
Part V: Appendices
您无需了解太多关于极限编程的知识即可阅读本书并从中受益。然而，由于用户故事起源于极限编程，附录 A对其进行了简要介绍。附录 B包含对大部分章节结束时的问题的回答。
You do not need to know much about Extreme Programming to read and benefit from this book. However, since user stories had their genesis in Extreme Programming, Appendix A provides a brief introduction to it. Appendix B contains answers to the questions that concluded most of the chapters.
附录 A. 极限编程概述
Appendix A. An Overview of Extreme Programming
本附录简要介绍了极限编程 (XP) 的主要思想。如果您已经熟悉 XP，则可以放心地跳过本附录。如果没有，请使用本附录作为 XP 的介绍，然后阅读一本详细解释 XP 的好书。[1]
This appendix serves as a brief introduction to the main ideas of Extreme Programming (XP). If you are already familiar with XP you can safely skip this appendix. If not, please use this appendix as an introduction to XP and then proceed to one of the fine books that explain XP in detail.[1]
我们将首先了解参与 XP 项目的人员（或角色）。接下来我们将看看 XP 的十二个主要实践。最后，我们将考虑 XP 团队的价值观。
We’ll look first at the people (or roles) involved in an XP project. Next we’ll look at the twelve main practices of XP. We’ll conclude by considering the values of an XP team.
角色
Roles
XP 客户角色负责编写故事、确定故事的优先级以及编写和执行证明故事按预期开发的测试。XP 客户可能是正在构建的系统的用户，但这不是必需的。如果不是用户，XP 客户通常是产品经理、项目经理或业务分析师。
The XP customer role is responsible for writing stories, prioritizing stories, and writing and executing tests that demonstrate that stories were developed as expected. The XP customer may be a user of the system being built but that is not necessary. If not a user, the XP customer is often a product manager, project manager or business analyst.
在某些项目中，客户角色实际上可能由客户团队担任，该团队由多个高度感兴趣的个人组成。客户团队通常包括协助创建验收测试的测试人员。当一个项目有多个客户时，他们用同一种声音说话很重要。他们可以通过多种方式实现这一点，但最常见的是在客户团队中指定一个人作为平等中的第一人。
On some projects the customer role may actually be filled by a customer team, which would be composed of multiple highly interested individuals. The customer team will often include testers who assist with creating the acceptance tests. When a project has multiple customers, it is important that they speak with one voice. They can achieve this in many ways, but most commonly by designating one individual on the customer team as the first among equals.
XP 程序员角色包含范围广泛的技术技能。XP 项目往往不区分程序员、设计师、数据库管理员等。所有程序员都应该作为一个团队工作，并分担许多责任，否则这些责任可能会分配给非 XP 项目中的特定个人。几乎所有流程都希望程序员对其代码进行单元测试；XP 认真对待这种期望，希望程序员为他们编写的所有内容开发自动化单元测试。
The XP programmer role encompasses a broad range of technical skills. XP projects tend not to draw distinctions between programmers, designers, database administrators, and so on. All programmers are expected to work as a team and to share many responsibilities that might otherwise be assigned to specific individuals on a non-XP project. Almost all processes expect programmers to unit test their code; XP takes this expectation seriously and programmers are expected to develop automated unit tests for everything they write.
最后，许多 XP 团队受益于 XP 教练和项目经理的使用。这些角色有时会结合在一个人身上。教练负责监督团队对 XP 实践的使用，并在他们偏离正轨时轻轻地将他们推回正轨。项目经理比经理更像是领导者，负责保护团队免受官僚作风的影响，并尽可能多地消除障碍。
Finally, many XP teams benefit from the use of an XP coach and possibly a project manager. The roles are sometimes combined within a single individual. The coach is responsible for monitoring the team’s use of the XP practices and gently nudging them back on track when they stray. The project manager is more leader than manager and is responsible for sheltering the team from bureaucracy and removing as many obstacles as possible.
十二种做法
The Twelve Practices
极限编程的特点是 Kent Beck 的原始“白皮书”（Beck 2000）中描述的十二种实践。如果您选择在一个项目上尝试 XP，我们强烈建议您采用所有的实践。XP 的十二个实践是高度协同和相互依赖的。实践相互支持并相互促进。例如，结对编程、简单设计、集体所有权、持续集成和测试的实践使重构实践变得更容易。十二种实践并不是一个随机的好点子集合，XP 团队可以从中挑选他们最喜欢的点子。在熟悉了 XP 之后，您可以选择放弃或改变一种做法，但您确实应该推迟定制 XP，直到熟悉标准 XP 为止。
Extreme Programming is characterized by the twelve practices described in Kent Beck’s original “white book” (Beck 2000). If you choose to try XP on a project, you are highly encouraged to adopt all of the practices. XP’s twelve practices are highly synergistic and interdependent. Practices support and enable each other. For example, the practice of refactoring is made easier by the practices of pair programming, simple design, collective ownership, continuous integration, and testing. The twelve practices are not a random collection of good ideas from which an XP team is allowed to pick their favorites. After becoming experienced with XP, you may choose to drop or alter a practice but you really should delay customizing XP until becoming experienced with standard XP.
在本附录中，我们将考虑以下十二种 XP 实践：
In this appendix we will consider the following twelve XP practices:
- 小版本
- small releases
- 计划游戏
- the planning game
- 重构
- refactoring
- 测试
- testing
- 结对编程
- pair programming
- 可持续的步伐
- sustainable pace
- 团队代码所有权
- team code ownership
- 编码标准
- coding standard
- 简单的设计
- simple design
- 隐喻
- metaphor
- 持续集成
- continuous integration
- 现场客户
- on-site customer
小版本
Small Releases
XP 项目在一系列迭代中取得进展，每个迭代通常持续一到三周。用户故事所描述的功能在单次迭代中完全交付。团队不允许交付一半的功能。同样，不允许团队交付全部功能，而只能交付一半的质量。在每次迭代结束时，团队负责交付可立即投入使用的有效、经过测试的代码。
XP projects progress in a series of iterations, each of which is each typically one to three weeks long. Features, as described by user stories, are fully delivered within a single iteration. A team is not allowed to deliver half of a feature. Similarly, a team is not allowed to deliver the full feature but at half the quality. By the end of each iteration the team is responsible for delivering working, tested code that can immediately be put to use.
在项目开始时，团队选择将在项目持续期间使用的迭代长度。迭代长度通常为一到两周，绝不会超过四周。团队应选择尽可能短的迭代长度，但仍能为业务带来有形价值。当在两个持续时间之间犹豫不决时，选择较短的一个。
At the start of the project the team selects an iteration length that it will use for the duration of the project. The iteration length is typically one or two weeks and never longer than four. The team should select an iteration length that is as short as possible yet that will still deliver tangible value to the business. When undecided between two durations, choose the shorter one.
迭代是固定的时间框。团队无法到达计划的迭代最后一天并决定他们还需要两天。迭代在预定日期结束。调整团队所做的工作量（但不是工作的质量）以适应迭代。
Iterations are firm timeboxes. A team cannot reach the planned last day of an iteration and and decide they need two more days. The iteration ends on the scheduled day. The amount of work the team does (but not the quality of that work) is adjusted to accommodate the iteration.
规划游戏
The Planning Game
“规划游戏”是发布和迭代规划的 XP 名称，在此期间开发人员和客户协作对未来进行预测。在开始规划之前，客户已将用户故事写在记事卡上，开发人员已估算每个故事的成本或规模，并将估算值写在故事卡上。
The “Planning Game” is the XP name for release and iteration planning during which the developers and customer collaboratively make predictions about the future. Prior to initiating planning, the customer has written user stories on note cards and the developers have estimated the cost or magnitude of each story and have written the estimate on the story card.
开始计划时，开发人员估计在为项目选择的长度的迭代中他们可以完成多少工作。然后客户查看所有故事卡并选择她最优先的故事以包含在第一次迭代中。她被允许选择总和但不超过开发人员估计他们在迭代中可以完成的工作量的故事。一旦第一次迭代充满了工作，客户就会开始为第二次和后续迭代选择故事。
To start planning, the developers estimate how much work they can complete in an iteration of the length selected for the project. The customer then looks over all of the story cards and selects her top priority stories for inclusion in the first iteration. She is allowed to select stories that sum to but do not exceed the amount of work the developers estimate they can do in the iteration. Once the first iteration is full of work, the customer moves onto selecting stories for the second and subsequent iterations.
经过一些迭代后，客户决定将足够多的故事放入迭代中，他们共同定义了一个版本。发布计划几乎肯定不会准确反映将开发什么以及按什么顺序开发。发布计划是关于开发如何进行的假设，但它会在每次迭代开始时随着优先级的变化而更新，随着团队对进度的了解越来越多，以及随着开发人员对真实预期成本的了解越来越多每个故事。
After some number of iterations, the customer decides that enough stories have been placed into iterations that collectively they define a release. The release plan almost certainly does not accurately reflect what will be developed and in what order. The release plan is a hypothesis about how development may proceed but it will be updated at the start of each iteration as priorities change, as more becomes known about the rate of progress by the team, and as the developers learn more about the true expected costs of each story.
在每次迭代开始之前，团队和客户计划迭代。这包括选择可以在迭代中完成的最高优先级故事，然后确定完成故事所需的特定任务。
Prior to the start of each iteration, the team and customer plan the iteration. This involves selecting the highest priority stories that can be completed in the iteration and then identifying the specific tasks necessary to complete the story.
重构
Refactoring
重构（Fowler 1999；Wake 2003）是指重构或重写代码，以在不改变其外部行为的情况下改进代码。随着时间的推移，代码会变得丑陋。为一个目的设计的方法略有改变以处理特殊情况。然后，由于它已经处理了那个特殊条件，所以它再次更改以处理另一个特殊条件。依此类推，直到该方法变得太脆弱而无法进一步修改。
Refactoring (Fowler 1999; Wake 2003) refers to the restructuring or rewriting of code so as to improve the code without changing its external behavior. Over time code can get ugly. A method designed for one purpose is changed slightly to handle a special condition. Then, since it already handles that special condition, it’s changed again to handle another special condition. And so on until the method becomes too fragile for further modification.
XP 提倡持续关注重构。每当程序员对应该重构的代码进行更改时，她就需要重构它。不鼓励她重构它；她需要重构它。通过这种方式，代码避免了缓慢的、有时难以检测的最终导致过时的衰退。
XP advocates constant attention to refactoring. Whenever a programmer makes a change to code that should be refactored, she is required to refactor it. She’s not encouraged to refactor it; she’s required to refactor it. In this way code avoids the slow, sometimes hard to detect decay that eventually results in obsolescence.
重构是 XP 用来替代前期设计的技术之一。XP 系统不是在编码之前花时间预先思考系统，因此猜测其行为的某些方面，而是重构并保持在完全满足已知、已实施要求的状态。
Refactoring is one of technique used by XP to replace upfront design. Rather than spending time upfront thinking through a system in advance of coding it, and therefore taking guesses at some aspects of its behavior, XP systems are refactored and kept in a state that perfectly meets known, implemented requirements.
测试
Testing
XP 的一个令人兴奋的实践是它对测试的关注。在 XP 项目中，开发人员编写自动化单元测试，客户编写验收测试，这些测试通常由客户自己或在开发人员的帮助下自动完成。许多 XP 开发人员确实发现了早期和频繁测试的好处。此外，开发人员对测试的传统抵制已经减弱，因为 XP 单元测试通常通过编写测试操作代码的测试代码来自动化——也就是说，即使在测试时它们也在编程。
An exciting practice of XP is its focus on testing. On an XP project the developers write automated unit tests and the customers write acceptance tests, which are often automated either by the customers themselves or with some help from the developers. Many XP developers have really found the benefits of early and frequent testing. Further, traditional resistance by developers to testing has gone down because XP unit tests are typically automated by writing test code that exercises the operational code—that is, even while testing they are programming.
在传统的开发中，测试是在代码之后编写的（如果它们被编写的话）。这成为一个问题，因为一旦代码被编写出来并且看起来可以工作，不对代码施加太大压力可能是人类的天性。因此，许多开发人员轻轻地推动他们的代码并将其称为测试。（我知道这一点：我曾经是他们中的一员。）XP 改变了这一点，并在称为测试驱动开发的实践中将测试放在最前面（Beck 2003；Astels 2003）。
In traditional development tests are written after the code (if they’re written at all). This becomes a problem because once code is written and appears to work, it can be human nature not to push too hard on the code. So, many developers push gently on their code and call it tested. (I know this: I used to be one of them.) XP changes this and puts the tests right up front in a practice called test-driven development (Beck 2003; Astels 2003).
在测试驱动开发中，测试先于代码编写。开发人员遵循测试-代码-测试-代码等的短周期（几分钟，而不是几小时）。他们遵循一条规则，即除非响应失败的测试，否则不得编写任何操作代码。因此，他们编写了一个失败的测试。运行该程序以验证测试是否失败。只有这样，程序员才能编写使程序通过测试的代码。
In test-driven development, tests are written before the code. Developers follow a short (minutes, not hours) cycle of test–code–test–code and so on. They follow a rule that no operational code may be written except in response to a failing test. So, they write a test that fails. The program is run to verify that the test fails. Only then does a programmer write the code that makes the program pass the test.
测试驱动开发保证代码将保持良好的分解和可测试性。它还会导致更易于维护的代码，因为代码从一开始就有效地处于维护模式。
Test-driven development guarantees that code will remain well factored and testable. It also leads to more maintainable code since code is effectively in a maintenance mode right from the start.
除了程序员单元测试，客户测试也是XP的重要组成部分。对于每个故事，客户负责定义一系列测试，用于确定故事是否按照客户的期望和假设开发。在许多方面，这些客户编写的验收测试取代了瀑布流程的需求文档。
In addition to programmer unit testing, customer tests are an important part of XP. For each story, the customer is responsible for defining a series of tests that are used to determine if the story was developed in accordance with the customer’s expectations and assumptions. In many ways, these customer-written acceptance tests replace the requirements documents of a waterfall process.
结对编程
Pair Programming
XP 比较有争议的做法之一是结对编程。结对编程是指两个程序员共享一个键盘和一个显示器，但使用他们的两个大脑来编写代码。当一个程序员在键盘上敲击（并在脑海中思考他的代码前面的几行）时，第二个程序员正在观察代码的开发并更广泛地思考代码可能会导向哪里以及它可能会遇到什么问题。两人经常互换角色和搭档。
One of XP’s more controversial practices is pair programming. Pair programming refers to two programmers sharing one keyboard and one monitor but using their two brains to write code. While one programmer is typing at the keyboard (and mentally thinking a few lines ahead in his code), the second programmer is watching the code develop and thinking more broadly about where the code may lead and what problems it may encounter. Pairs switch roles and partners often.
虽然结对编程听起来效率极低，但Alistair Cockburn 和 Laurie Williams (2001)对其进行了研究并发现事实并非如此。他们发现，如果总编程时间增加 15%，结对编程会导致：
While pair programming may sound tremendously inefficient, Alistair Cockburn and Laurie Williams (2001) have studied it and found that not to be the case. They found that for a 15% increase in total programming time, pair programming leads to:
- 更低的缺陷数
- lower defect counts
- 编写更少的代码来解决同样的问题
- less code is written to solve the same problem
- 问题得到更快解决
- problems being solved more quickly
- 让更多人理解每段代码
- more people understand each piece of code
- 提高开发人员的工作满意度
- an increase in developer job satisfaction
结对编程对 XP 很重要，因为许多其他 XP 实践都需要纪律。每次您注意到结构不佳的代码或始终在编写可操作代码之前编写测试时，都需要大量的纪律来重构。如果没有一对，带着“就这一次……”的想法跳过重构或测试可能太诱人了。
Pair programming is important to XP because so many of the other XP practices require discipline. It requires a tremendous amount of discipline to refactor every time you notice poorly structured code or to always write tests before writing operational code. Without a pair it can be far too tempting to skip a refactoring or a test with the thought of “Just this once…”
可持续步伐
Sustainable Pace
鼓励 XP 团队以可持续的速度工作。人们相信，一个以一致但轻快的步伐前进的 XP 团队将在一段时间内取得比以他们无法长期维持的步伐工作的团队更多的成就。这并不意味着 XP 团队每周刚好工作 40 小时，然后就回家了。由团队决定他们的持续步伐，并且团队的不同成员可能会有所不同。
XP teams are encouraged to work at a sustainable pace. The belief is that an XP team moving at a consistent but brisk pace will achieve more over a period of time than will a team working at a pace they cannot sustain over a long period. This does not mean that an XP team works exactly forty hours each week and then heads for home. It is up to the team to determine their sustained pace, and it is likely to be different for different members of the team.
结对编程和测试驱动开发是有效的，因为它们将结对的思想集中在他们正在创建的代码上。很少有人能够长时间保持这种强度水平。一个团队通常每天会花大约 6 个小时来结对，然后将剩下的时间花在其他活动上。
Pair programming and test-driven development are effective because they focus the minds of the pair very intensely on the code they are creating. Few people are capable of maintaining this level of intensity for extended periods. A team will typically devote around six hours per day to pairing and spend the remainder of the day in other activities.
XP 教练负责监控团队的倦怠情况。如果教练感觉到团队正在精疲力尽，她将帮助团队重新以可持续的速度工作。
An XP coach is responsible for monitoring the team for burnout. If the coach senses a team is burning out she will help the team shift back to working at a sustainable pace.
团队代码所有权
Team Code Ownership
在非 XP 团队中，个人开发人员“拥有”或承担部分系统代码的全部责任是很常见的。通过这种方式，系统的每个部分都将由一个开发人员拥有——至少在开发人员转移到另一个项目并且她的代码没有所有者之前是这样。这种对代码所有权的看法也导致团队发表评论，例如“在 Eli 休假回来之前，我们不能更改计费源代码。” 此外，如果在 Eli 休假期间说服开发人员更改代码，Eli 回来后可能会对“他的代码”所做的更改感到生气。
It has been common among non-XP teams for individual developers to “own” or assume full responsiblity for portions of a system’s code. In this way each portion of a system would be owned by one developer—at least until a developer moves onto another project and her code is left without an owner. This view toward code ownership also leads teams to make comments such as “We can’t change the billing source code until Eli gets back from vacation.” Further, if a developer is talked into changing the code while Eli is on vacation, Eli will probably be angry about changes made to “his code” when he returns.
XP 团队对代码所有权采取完全不同的方法：所有代码都属于每个人。在这种团队所有权模型下，任何一对开发人员都可以更改任何代码。事实上，由于重构实践，人们希望结对更改不是他们编写的代码。
XP teams take a completely different approach to code ownership: All code is owned by everyone. Under this model of team ownership, any pair of developers can change any code. In fact, because of the refactoring practice, pairs are expected to change code they didn’t write.
实行个人所有权以确保连贯的设计并保持模块的所有责任平衡。在XP中，这个负担由测试驱动来承担发展。一套强大的单元测试确保更改不会引入意外的副作用。
Individual ownership is practiced to ensure coherent design and to keep all responsibilities of a module balanced. In XP, this burden is borne by test-driven development. A strong suite of unit tests ensures that changes do not introduce unanticipated side effects.
编码标准
Coding Standards
因为 XP 团队集体拥有他们的源代码，所以他们遵循编码标准很重要。编码标准列出了团队成员在编写代码时将遵循的主要规则和约定：如何命名变量和方法？行将如何格式化？等等。
Because XP teams collectively own their source code, it is important that they follow a coding standard. The coding standard lays out the main rules and conventions team members will follow when writing code: how will variables and methods be named? how will lines be formatted? and so on.
一个小型的、紧密结合的团队也许可以在没有书面的、正式的编码标准的情况下通过。他们可以通过团队民间传说建立和共享标准。除了少数开发人员之外，大多数团队都将从写下他们的编码标准中受益，但仍然尽可能保持它们的简短和必要。
A small, close-knit team may be able to get by without a written, formalized coding standard. They can build and share standards through team folklore. Beyond a handful of developers, most teams will benefit from writing down their coding standards but still keeping them as brief and essential as possible.
简单的设计
Simple Design
XP 团队追求的目标是拥有尽可能简单的设计，以提供客户需要的功能。Kent Beck (2000)定义了四个约束，指示设计何时可以是最简单的：
XP teams pursue a goal of having the simplest possible design that delivers the features a customer needs. Kent Beck (2000) defines four constraints that indicate when a design is the simplest it can be:
1. 运行代码和测试代码充分传达了程序员对该代码行为的意图。
1. The operational code and the test code fully convey the programmer’s intent for the behavior of that code.
2.没有重复代码。
2. There is no duplicated code.
3.系统使用最少的班级。
3. The system uses the least number of classes.
4.系统使用最少的方法。
4. The system uses the least number of methods.
隐喻
Metaphor
XP 团队通过寻找可用于整个系统的隐喻来支持对简单设计的追求。这个比喻为他们如何看待系统提供了一个参考框架。例如，在一个项目中，我们的比喻是系统就像一块黑板，系统的各个部分都可以在黑板上书写。当用户使用完系统后，她要么保存黑板的内容，要么将其擦除。这种极大简化的系统思考方式为我们提供了一种方便、简单的系统行为思考方式，从而帮助了我们。
XP teams support the quest for simple design by finding a metaphor that can be used for the whole system. The metaphor provides a frame of reference for how they think about the system. For example, on one project our metaphor was that the system was like a chalkboard and that various parts of the system could write on the chalkboard. When the user was done with the system she would either save the contents of the chalkboard or erase them. This greatly simplified way of thinking about the system helped us by giving us a convenient, simple way of thinking about the behavior of the system.
持续集成
Continuous Integration
我最近参与了与最大电子商务公司之一的一位高管的讨论。他告诉我，集成多个开发人员的工作是大多数软件开发团队面临的最大问题。他喜欢让他的团队每月集成一次他们的软件，这样他们就可以避免因集成频率较低而带来的更大问题。我问他，如果他的团队每天都进行整合，会发生什么情况。
I got involved in a discussion recently with an executive at one of the largest eCommerce companies. He told that me that integrating the work of multiple developers was the largest problem for most software development teams. He liked to have his teams integrate their software once a month so they could avoid the bigger problems of integrating less frequently. I asked him what would happen if his teams instead integrated on a daily basis.
XP 团队知道答案，他们至少每天都进行整合。我们很久以前就了解了每日构建和冒烟测试的好处（Cusumano 和 Selby 1995）。XP 团队已将此带到或多或少持续集成代码的地步。例如，开发人员完成了一个小的更改，她将更改签入源代码存储库，其中一个流程会注意到更改并启动完整构建。构建完成后，将运行一套自动化测试。如果任何测试失败，开发人员将收到电子邮件并告知失败情况。一旦出现集成问题，就会以极小的批次一次解决一个问题。
XP teams know the answer and they integrate at least daily. We learned long ago about the benefits of a daily build and smoke test (Cusumano and Selby 1995). XP teams have taken this to the point where code is integrated more or less continuously. For example, a developer completes a small change, she checks the change into the source code repository where a process notices the change and initiates a full build. When the build is complete a suite of automated tests is run. If any of the tests fail, the developer is emailed and told about the failure. Integration problems are fixed one at a time in extremely small batches as soon as they occur.
现场客户
On-Site Customer
过去，客户通常会编写需求文档，将其翻墙扔给编写代码的程序员，然后再将系统翻墙扔给一些测试人员。有了 XP，围墙就消失了，客户被期望与开发团队坐在一起并成为开发团队的一员。客户编写故事和验收测试，并在问题出现时立即回答。
It used to be common for a customer to write a requirements document, throw it over a wall to the programmers who would write the code and then throw the system over another wall to some testers. With XP the walls are gone and the customer is expected to sit with and be part of the development team. The customer writes the stories and the acceptance tests and also is on hand to answer questions as soon as they arise.
现场客户对于成功使用用户故事方法至关重要，因为客户和开发人员之间必须进行许多对话。如果客户不在现场，延迟将扰乱 XP 团队的可预测进度。
The on-site customer is essential to successful use of the user story approach because of the many conversations that must occur between the customer and the developers. If the customer is not on site, delays will disrupt the predictable progress of the XP team.
XP的价值观
XP’s Values
除了实践之外，XP 还提倡四种价值观：沟通、简单、反馈和勇气。XP 重视沟通，但并非所有的沟通方式都是平等的。最理想的是面对面的交流，我们可以在其中交谈、回应、做手势和在白板上画画。不太理想的是书面文件。XP 强调通过结对编程等实践进行交流。
In addition to its practices, XP advocates four values: communication, simplicity, feedback and courage. XP values communication but not all modes of communication are equal. Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming.
简单是 XP 团队的价值观，因为它使他们专注于为今天面临的问题创建解决方案，而不是明天预期的问题。XP 团队构建的系统所支持的功能超出了开发当前迭代的功能所必需的功能。他们始终专注于做可能可行的最简单的事情。
Simplicity is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow. XP teams do not architect a system with support for features beyond those that are necessary for developing the features of the current iteration. They remain constantly focused on doing the simplest thing that could possibly work.
XP 团队重视反馈，反馈越及时越好。当一位开发人员向她的结对指出潜在问题时，XP 开发人员会在结对编程期间提供并获得反馈。他们从经常运行的自动化测试中获得反馈。他们从持续（或至少每天）的集成过程中获得反馈。客户是团队的一部分，甚至与开发人员坐在同一个空间，并通过与团队的不断互动以及他们编写的验收测试提供反馈。
XP teams value feedback, and the more immediate the feedback the better. XP developers give and get feedback during pair programming when one developer points out a potential problem to her pair. They get feedback from the automated tests they run so often. They get feedback from their continuous (or at least daily) integration process. Customers are part of the team, even sitting in the same space with the developers, and provide feedback through constant interaction with the team and through the acceptance tests they write.
最后，XP 团队重视勇气。例如，他们有勇气重构他们的代码（因为他们有自动化测试来支持这种勇气）。他们有勇气在没有总体架构的情况下继续前进，因为他们将使用一个比喻，并通过重构和测试驱动开发来保持简单的设计。
Finally, XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage). They have courage to proceed without an overall master architecture because they will use a metaphor and maintain a simple design through refactoring and test-driven development.
XP的原则
The Principles of XP
除了它的价值观和实践之外，XP 还可以通过它的五个基本原则来表征：快速反馈、假设简单、增量变化、拥抱变化和做高质量的工作（Beck 2000）。自从引入 XP 以来，关于一个团队如果只做最初十二种实践中的十一种是否可以做 XP 的争论一直很激烈。一个不结对编程的团队在做XP吗？一个追求简单设计但从几个星期的建模开始的团队是做 XP 的吗？
In addition to its values and practices, XP can be characterized by its five basic principles: rapid feedback, assuming simplicity, incremental change, embracing change, and doing quality work (Beck 2000). Since the introduction of XP, a debate has raged over whether a team can be doing XP if they doing only eleven of the original twelve practices. Is a team that doesn’t pair program doing XP? Is a team that pursues a simple design but starts with a few weeks of modeling doing XP?
我认为答案是肯定的。如果这些团队遵循 XP 的原则，那么他们就是在做 XP。一个团队：
I think the answer is yes. These teams are doing XP if they are living by the principles of XP. A team that:
- 向客户提供快速反馈并从该反馈中学习
- provides rapid feedback to its customers and learns from that feedback
- 喜欢简单，总是先尝试简单的解决方案，然后再转向更复杂的解决方案
- favors simplicity and always attempts a simple solution before moving to a more complex one
- 通过小的增量更改改进软件
- improves the software through small, incremental changes
- 拥抱变化，因为他们知道自己真正善于适应和适应
- embraces change because they know they are truly adept at accommodating and adapting
- 并且，坚持认为该软件始终如一地展现出最高水平的质量工艺
- and, insists that the software consistently exhibits the highest level of quality workmanship
肯定是在做 XP，即使他们错过了一两次练习。
must certainly be doing XP, even if they missing a practice or two.
概括
Summary
- XP 客户角色负责为每个故事编写故事和验收测试，并与开发团队坐在一起。
- The XP customer role is responsible for writing stories and acceptance tests for each story, and sits with the development team.
- 在 XP 项目中，程序员和测试人员之间的区别是模糊的。程序员编写自己代码的单元测试；测试人员编写自动验收测试程序。
- On an XP project the distinction between programmer and tester is blurred. Programmers write unit tests of their own code; testers program automated acceptance tests.
- XP 项目包括一名教练，可能还包括一名单独的项目经理，负责指导团队并消除前进道路上的障碍。
- XP projects include a coach and possibly a separate project manager who are responsible for guiding the team and removing obstacles from its way.
极限编程涉及以下实践：
Extreme Programming involves the following practices:
- 小版本
- small releases
- 计划游戏
- the planning game
- 重构
- refactoring
- 测试
- testing
- 结对编程
- pair programming
- 可持续的步伐
- sustainable pace
- 集体代码所有权
- collective code ownership
- 编码标准
- coding standard
- 简单的设计
- simple design
- 隐喻
- metaphor
- 持续集成
- continuous integration
- 现场客户
- on-site customer
并具有以下值：
And has these values:
并具有以下关键原则：
And has these key principles:
附录 B. 问题的答案
Appendix B. Answers to Questions
第 1 章，概述
Chapter 1, An Overview
1.1用户故事的三个部分是什么？
1.1 What are the three parts of a user story?
答案：卡片、对话和确认。
Answer: Card, Conversation, and Confirmation.
1.2客户团队中有哪些人？
1.2 Who is on the customer team?
回答：客户团队包括确保软件满足其预期用户需求的人员。这可能包括测试人员、产品经理、真实用户和交互设计师。
Answer: The customer team includes those who ensure that the software will meet the needs of its intended users. This may include testers, a product manager, real users, and interaction designers.
1.3以下哪个不是好故事？为什么？
1.3 Which of the following are not good stories? Why?
表 B.1。 问题 1.3 的答案。
Table B.1. Answer to Question 1.3.
1.4需求对话比需求文档有什么优势？
1.4 What advantages do requirements conversations have over requirements documents?
答：书面文件意味着他们无法反驳的精确性。用户故事，以卡片作为对话的提醒，避免了高度精确的假象。把事情写下来并不能保证客户会得到他们想要的东西；充其量客户会得到写下来的东西。频繁的对话，尤其是在所讨论的功能开发过程中以及接近开发过程中的对话，可以在开发人员和客户之间加深和共享理解。
Answer: Written documents imply a precision that they can’t back. User stories, with cards as reminders to hold conversations, avoid the false appearance of being highly precise. Writing things down is no guarantee that customers will get what they want; at best customers will get what was written down. Frequent conversations, especially ones close to and during development of the feature being discussed, lead to greater and shared understanding between the developers and customers.
1.5为什么要在故事卡背面写测试？
1.5 Why would you want to write tests on the back of a story card?
回答：在卡片背面写测试是客户传达她对故事的期望和假设的好方法。
Answer: Writing tests on the back of a card is a great way for the customer to communicate her expectations and assumptions about a story.
第 2 章，写故事
Chapter 2, Writing Stories
2.1对于下列故事，请指出是不是好故事。如果不是，为什么？
2.1 For the following stories, indicate if it is a good story or not. If not, why?
2.2将这个史诗分成适当大小的组件故事：“用户可以制作和更改自动求职代理。”
2.2 Break this epic up into appropriately sized component stories: “A user can make and change automated job search agents.”
答：这部史诗至少应该分成两个故事，一个是制作一个，一个是更换代理人。但是，它可以以多种不同的方式拆分，具体取决于故事可能需要多长时间才能实现。一种可能的分解是：
Answer: Minimally this epic should be split into two stories, one to make and one to change agents. However, it could be split many different ways, depending on how long the stories are likely to take to implement. One possible disaggregation is:
• 用户可以制作一个自动求职代理。
• A user can make an automated job search agent.
• A user can edit the search parameters of an automated job search agent.
• 用户可以更改自动求职代理的运行时间。
• A user can change the times when an automated job search agent will run.
• 用户可以更改自动求职代理结果的报告方式。
• A user can change how the results of an automated job search agent will be reported.
表 B.2。 问题 2.1 的答案。
Table B.2. Answer to Question 2.1.
第 3 章，用户角色建模
Chapter 3, User Role Modeling
3.1看看 eBay 网站。您可以识别哪些用户角色？
3.1 Take a look at the eBay website. What user roles can you identify?
回答：您的列表应包括一些类似于以下的角色：一次性卖家、小卖家、常客、不经常买家、常客、企业卖家、制造商、支付处理商、收藏家、俱乐部会员、软件开发商、附属机构、无线卖家、无线买家
Answer: Your list should include some roles similar to these: One-time Seller, Small Seller, Frequent Seller, Infrequent Buyer, Frequent Buyer, Corporate Seller, Manufacturer, Payment Processor, Collector, Club Member, Software Developer, Affiliate, Wireless Seller, Wireless Buyer
3.2整合你在上一个问题中想到的角色，并展示你将如何布置角色卡。解释你的答案。
3.2 Consolidate the roles you came up with in the previous question and show how you would lay out the role cards. Explain your answer.
回答：在我的列表中，我将卖家合并为一个通用卖家角色和三个更专业的卖家：小型卖家、常客和公司卖方。同样，我有一个通用的买家角色，专门负责稀有买家、常客和收藏家。我还保留了支付处理器、附属公司和通用无线用户。
Answer: From my list, I consolidated sellers into a generic Seller role and three more specialized sellers: Small Seller, Frequent Seller and Corporate Seller. Similarly, I had a generic Buyer role specialized into Infrequent Buyer, Frequent Buyer and Collector. I also kept Payment Processor, Affiliate and a generic Wireless User.
3.3为最重要的用户角色编写角色描述。
3.3 Write persona descriptions for the one most important user role.
答案：布伦达是常客。通常在一周内，她每天至少访问该网站一次，平均每周购买一到两次商品。她通常购买电影和书籍，但她也购买园艺和厨房用品。她是一名房地产经纪人，在我们的网站上非常自在，但在学习大多数新软件时有点不舒服。她通常通过家中的拨号连接访问该站点，但偶尔会通过更快的办公室连接访问该站点。
Answer: Brenda is a Frequent Buyer. During a typical week she visits the site at least once a day, and makes an average of one or two purchases per week. She typically buys movies and books but she has also purchased gardening and kitchen items. She is a realtor and is very comfortable on our site but is a little uncomfortable learning most new software. She usually accesses the site from her dial-up connection at home but occasionally accesses it from her faster office connection.
第 4 章，收集故事
Chapter 4, Gathering Stories
4.1如果团队仅通过使用问卷收集需求，您会遇到什么问题？
4.1 What problems would you expect if a team only gathered requirements through the use of questionnaires?
回答：调查问卷可能需要很长时间才能完成，因此项目将需要更长的时间才能完成。需要有人汇总和解释结果，这意味着会有一定程度的误解。因为调查问卷不提供真正的双向沟通，所以团队很难获得关于是否在正确轨道上的反馈。
Answer: Questionnaires can take a long time to turn around so the project will take longer to complete. Someone will need to aggregate and interpret the results, which means there will be some degree of misinterpretation. Because questionnaires do not provide for true two-way communication, it will be extremely hard for a team to get feedback as to whether it’s on the right track.
4.2将以下问题重新表述为上下文无关和开放式的。你认为用户应该输入密码吗？系统是否应该每 15 分钟自动保存一次用户的工作？一个用户可以看到另一个用户保存的数据库条目吗？
4.2 Rephrase the following questions to be context free and open-ended. Do you think the user should have to enter a password? Should the system automatically save the user’s work every 15 minutes? Can one user see database entries saved by another user?
回答：有很多方法可以改写这些。这里有些例子：
Answer: There are many ways to reword these. Here are some examples:
• 描述系统应如何保护敏感数据。
• Describe how the system should safeguard sensitive data.
• 如果系统在她使用时崩溃了，用户会怎么做？
• What would a user do if the system crashed while she was using it?
• 告诉我有关用户保存的数据的可访问性。
• Tell me about the accessibility of data saved by a user.
4.3为什么最好问开放式、无关上下文的问题？
4.3 Why is it best to ask open-ended, context-free questions?
答案：无关上下文的问题并不意味着答案（“你什么时候停止打你妻子的？”）所以受访者觉得没有必要给出“正确”的答案。开放式问题允许详细回答，而不仅仅是简单的是或否。开放式、上下文无关的问题是最好的，因为它们不会影响响应，它们允许比是或否更广泛的响应。
Answer: Context-free questions do not imply an answer (“When did you stop beating your wife?”) so the respondent does not feel a need to give the “right” answer. Open-ended questions allow detailed responses that go beyond a simple yes or no. Open-ended, context-free questions are best because they do not influence the response and they allow a broader range of responses than yes or no.
第 5 章，使用用户代理
Chapter 5, Working with User Proxies
5.1使用用户管理员作为用户的代理会导致什么问题？
5.1 What problems can result from using the users’ manager as a proxy for the users?
回答：即使用户经理是该软件的当前用户，她的需求也几乎肯定与用户的需求不同。更糟糕的是，如果她是以前的用户，那么她对系统的了解已经过时了。
Answer: Even if the users’ manager is a current user of the software, her needs almost certainly differ from the needs of the users. Worse, if she is a former user, her knowledge of the system is outdated.
5.2使用领域专家作为用户代理会导致什么问题？
5.2 What problems can result from using a domain expert as a proxy for users?
回答：一个问题是领域专家可能不是系统的用户。如果她是，她对系统的使用可能不同于不太专业的用户。第二个问题是，您最终可能会得到一个非常适合专家的系统，但对于那些领域知识低于专家水平的人来说是无法使用的。
Answer: One problem is that the domain expert may not be a user of the system. If she is, her use of the system may differ from less expert users. A second problem is that you may end up with a system that is perfect for experts, but that is not usable by those with less than expert level domain knowledge.
第 6 章，验收测试用户故事
Chapter 6, Acceptance Testing User Stories
6.1谁指定测试？谁帮忙？
6.1 Who specifies the tests? Who helps?
答：客户指定测试。客户通常会与程序员或测试人员一起实际创建测试，但客户至少需要指定将用于了解何时正确开发故事的测试。
Answer: The customer specifies the tests. The customer will usually work with a programmer or tester to actually create the tests, but minimally the customer needs to specify the tests that will be used to know when a story has been correctly developed.
6.2为什么在故事编码之前指定测试？
6.2 Why specify tests before the stories are coded?
回答：在编码开始之前指定测试，因为它们是传达客户对新功能的假设的有用且有效的方法。
Answer: Tests are specified before coding begins because they are a useful and effective method for communicating the customer’s assumptions about the new functionality.
第 7 章，好故事的指导方针
Chapter 7, Guidelines for Good Stories
7.1假设“求职者可以搜索空缺职位”这个故事太大，无法放入一次迭代中。你会如何拆分它？
7.1 Assume the story “A Job Seeker can search for open jobs” is too large to fit into one iteration. How would you split it?
答：这个故事大概可以根据支持的搜索参数进行拆分，例如位置、关键词、职位、薪水等。此外，可能有不同的方式来呈现结果。最初的故事可能包含每个匹配工作的非常简单的列表。该故事可以通过故事进行扩充，以增强结果的显示，可能包含有关每个工作的更多详细信息，允许用户选择排序顺序或显示哪些字段，或者提供指向有关工作的更多详细信息的链接。
Answer: This story can probably be split based on the search parameters supported such as location, key words, job title, salary, and so on. Additionally, there may be different ways to present the results. An initial story might cover a very simple list of each matched job. That story could be augmented by a story to enhance the display of the results, perhaps with more details about each job, allowing the user to select a sort order or what fields are displayed, or providing a link to more details about the job.
7.2以下哪个故事的大小合适并且可以被认为是一个封闭的故事？
7.2 Which of these stories is appropriately sized and can be considered a closed story?
表 B.3。 问题 7.2 的答案。
Table B.3. Answer to question 7.2.
7.3哪些简单的改变可以改善“用户可以发布简历”的故事？
7.3 What simple changes could improve the story “Users can post their resumes”?
答：正如所写，不清楚用户是否可以发布多份简历。这无疑会在谈论故事时出现，但最好将故事写得更清楚，因为“求职者可以发布一份或多份简历”。
Answer: As written, it is not clear if a user can post multiple resumes. This undoubtedly will come out during conversations about the story, but it is better to write the story more clearly as “A Job Seeker can post one or more resumes.”
7.4你将如何测试“软件将易于使用”的约束条件？
7.4 How would you test the constraint “The software will be easy to use”?
答：为了测试这一点，您必须首先定义“易于使用”的含义。这是否意味着熟练的用户可以用最少的击键次数完成常见的任务？或者这是否意味着新用户可以快速达到给定的软件熟练程度？最常见的是后者。如果是这样，请定义一个或多个测试，例如：
Answer: In order to test this, you must first define what “easy to use” means. Does it mean that a skilled user can complete common tasks with a minimum number of keystrokes? Or does it mean that a new user can quickly achieve a given level of proficiency with the software? Most commonly it will mean the latter. If so, define one or more tests such as:
• 新用户可以在第一次看到系统后的30 分钟内搜索工作、在系统上注册并发布她的简历。
• A new user can search for a job, register on the system, and post her resume within 30 minutes of first seeing the system.
像这样的测试不能作为项目每晚构建的一部分来执行，但它们可以通过偶尔的可用性测试来验证，在此期间向新用户展示软件并进行观察。
Tests like these can’t be performed as part of a project’s nightly builds, but they can be verified by occasioanal usability testing during which new users are shown the software and observed.
第 8 章，估计用户故事
Chapter 8, Estimating User Stories
8.1在估算会议期间，三个程序员正在估算一个故事。他们分别在两个、四个和五个故事点上估计故事。他们应该使用哪种估计？
8.1 During an estimating meeting three programmers are estimating a story. Individually they estimate the story at two, four and five story points. Which estimate should they use?
回答：他们应该继续讨论这个故事，直到他们的估计越来越接近。
Answer: They should continue discussing the story until their estimates get closer.
8.2三角测量估计的目的是什么？
8.2 What is the purpose of triangulating estimates?
答案：三角测量通过确保每个估计相对于其他多个估计有意义来改进估计。如果一个两点故事看起来是一个单点故事的两倍，那么它也应该看起来是一个四点故事的一半。
Answer: Triangulation improves estimates by making sure that each estimate makes sense in relation to multiple other estimates. If a two-point story seems to be twice a one-point story, it should also seem to be one-half of a four-point story.
8.3定义速度。
8.3 Define velocity.
答案：速度是团队在一次迭代中完成的故事点数。
Answer: Velocity is the number of story points completed by a team in an iteration.
8.4 A 队在最后两周的迭代中完成了 43 个故事点。团队 B 正在从事一个单独的项目，并且拥有两倍的开发人员。他们还在最后两周的迭代中完成了 43 个故事点。这个怎么可能？
8.4 Team A finished 43 story points in their last two-week iteration. Team B is working on a separate project and has twice as many developers. They also completed 43 story points in their last two-week iteration. How can that be?
答：一个团队的故事点数无法与任何其他团队的故事点数相提并论。从这个问题的信息中，我们不能推断出 A 队的生产力是 B 队的两倍。
Answer: The story points of one team are not comparable to the story points of any other team. From the information in this question, we cannot infer that Team A is twice as productive as Team B.
第 9 章，计划发布
Chapter 9, Planning a Release
9.1估计团队初始速度的三种方法是什么？
9.1 What are three ways of estimating a team’s initial velocity?
回答：您可以使用历史值、进行猜测或运行初始迭代并使用该迭代的速度。
Answer: You can use historical values, take a guess, or run an initial iteration and use the velocity of that iteration.
9.2假设一周的迭代和一个由四名开发人员组成的团队，如果他们的速度为 4，团队需要多少次迭代才能完成一个有 27 个故事点的项目？
9.2 Assuming one-week iterations and a team of four developers, how many iterations will it take the team to complete a project with 27 story points if they have a velocity of 4?
答案：项目中的速度为 4 和 27 个故事点，团队需要 7 次迭代才能完成。
Answer: With a velocity of 4 and 27 story points in the project, it will take the team 7 iterations to finish.
第 10 章，计划迭代
Chapter 10, Planning an Iteration
10.1将这个故事分解成它的组成任务：用户可以查看有关酒店的详细信息。
10.1 Disaggregate this story into its constituent tasks: A user can view detailed information about a hotel.
答：当然，有很多方法可以做到这一点，但这里有一个：
Answer: There are, of course, many ways to do this, but here’s one:
• 设计这些网页的外观。
• Design the look of these web pages.
• 编写 HTML 代码以显示酒店和房间照片。
• Code the HTML to display hotel and room photos.
• 编写 HTML 代码以显示显示酒店位置的地图。
• Code the HTML to display a map showing where the hotel is.
• 编写 HTML 代码以显示酒店设施和服务的列表。
• Code the HTML to display a list of hotel amenities and services.
• 弄清楚我们是如何生成地图的。
• Figure out how we’re generating maps.
• 编写SQL 从数据库中检索信息。
• Write SQL to retrieve information from the database.
• 等等。
• And so on.
第 11 章，测量和监控速度
Chapter 11, Measuring and Monitoring Velocity
11.1估计在一个故事点的故事实际上需要两天时间才能完成。在迭代结束时计算时，它对速度有多大贡献？
11.1 A story estimated at one story point actually took two days to complete. How much does it contribute to velocity when calculated at the end of the iteration?
答：贡献一分。
Answer: It contributes one point.
11.2从每日燃尽图中可以学到哪些在迭代燃尽图中看不到的信息？
11.2 What can you learn from a daily burndown chart that you can’t see on an iteration burndown chart?
答：每日燃尽图显示团队在迭代期间的进度。您可以使用此信息来衡量是否所有计划的工作都将在迭代结束时完成。如果很明显不能完成所有工作，团队和客户可以在迭代期间讨论哪些工作应该推迟。
Answer: Daily burndown charts show the progress of the team during the iteration. You can use this information to gauge whether all planned work will be completed by the end of the iteration. If it becomes apparent that not all work can be completed, the team and customer can talk during the iteration about which work should be deferred.
11.3你应该从图 11.7中得出什么结论？该项目看起来会提前、延迟还是按计划完成？
11.3 What conclusions should you draw from Figure 11.7? Does the project look like it will finish ahead, behind or on schedule?
图 11.7。 这个项目会提前、推迟或按计划完成吗？
Figure 11.7. Will this project finish ahead, behind or on schedule?
回答：这个团队在第一次迭代中的开始比预期的要好一些。他们预计速度会在第二次和第三次迭代中提高，然后稳定下来。经过两次迭代后，他们已经达到了三次迭代后预期的速度。在这一点上，它们提前完成了，但您应该不愿意仅在两次迭代后就得出太多确定的结论。
Answer: This team started out a little better than anticipated in the first iteration. They expected velocity to improve in the second and third iterations and then stabilize. After two iterations they have already achieved the velocity they expected after three iterations. At this point they are ahead of schedule but you should be reluctant to draw too many firm conclusions after only two iterations.
11.4 What is the velocity of the team that finished the iteration shown in Table 11.3?
表 11.3。 迭代期间完成的故事。
Table 11.3. Stories completed during an iteration.
答：十六。部分完成的故事对速度没有贡献。
Answer: Sixteen. Partially completed stories do not contribute to velocity.
11.5什么情况会导致迭代燃尽图反映上升趋势？
11.5 What circumstances would cause an iteration burndown chart to reflect an upward trend?
回答：如果新工作的添加速度快于已知工作的完成速度，或者如果团队决定大量未来工作被低估，则迭代燃尽图将呈上升趋势。
Answer: An iteration burndown chart will trend upwards if new work is being added faster than known work is being completed, or if the team decides that a significant amount of future work has been underestimated.
11.6 Complete Table 11.4 by writing the missing values into the table.
表 11.4。 填写缺失值。
Table 11.4. Fill in the missing values.
Answer: The completed table appears as Table B.4.
表 B.4。 问题 11.6 的答案。
Table B.4. Answer to question 11.6.
第12章,什么故事不是
Chapter 12, What Stories Are Not
12.1用户故事和用例之间的主要区别是什么？
12.1 What are the key differences between user stories and use cases?
回答：用户故事通常包含比用例更小的范围。用户故事不像用例那样包含详细信息。用户故事在开发它们的迭代之后无用；用例通常旨在作为项目的永久工件。
Answer: A user story usually encompasses a smaller scope than a use case. User stories do not include as much detail as use cases. User stories are not intended to be useful after the iteration in which they are developed; use cases are often intended as permanent artifacts of a project.
12.2用户故事和 IEEE 830 需求陈述之间的主要区别是什么？
12.2 What are the key differences between user stories and IEEE 830 requirements statements?
回答： IEEE 830 风格的需求陈述侧重于解决方案的属性，而用户故事侧重于用户的目标。IEEE 830 需求规范鼓励团队预先编写所有需求声明，而不是像用户故事那样以迭代方式编写。在编写需求陈述时要格外小心，以确保用词传达正确的意思；用户故事承认对话在澄清细节方面的优越性。
Answer: IEEE 830-style requirements statements focus on the attributes of the solution, while user stories focus on the user’s goals. IEEE 830 requirements specifications encourage teams to write all of the requirements statements up front rather than in an iterative manner, as with user stories. Great care is taken in writing requirements statements to make sure the words convey the proper meaning; user stories acknowledge the superiority of conversations for clarifying details.
12.3用户故事和交互设计场景之间的主要区别是什么？
12.3 What are the key differences between user stories and interaction design scenarios?
答：交互设计场景比用户故事要详细得多，通常会非常详细地描述角色和系统使用的上下文。此外，场景通常比用户故事描述的范围更广。
Answer: Interaction design scenarios are much more detailed than user stories, often describing the persona and the context of the system use in great detail. Also, a scenario often describes a broader scope than does a user story.
12.4对于一个非平凡的项目，为什么不可能在项目开始时就写完所有的需求？
12.4 For a non-trivial project, why is it impossible to write all the requirements at the start of the project?
回答：试图在项目开始时写下所有需求会忽略一个重要的反馈循环。当系统的目标用户开始看到系统并与之交互时，新的需求就会浮现在脑海中。
Answer: Attempting to write all requirements at the start of a project ignores an important feedback loop. When a system’s intended users begin to see and interact with the system, new requirements come to mind.
12.5考虑用户的目标比列出要构建的软件的属性有什么好处？
12.5 What is the advantage to thinking about users’ goals rather than on listing the attributes of the software to be built?
回答：属性列表并不能像故事和对话那样让读者对产品有同样的整体理解。此外，如果我们的工作是由产品属性列表驱动的，那么当我们完成时，我们可以说交付的产品具有列表中的属性。这与说交付的产品满足用户的所有目标不同。
Answer: A list of attributes does not give the reader the same overall understanding of a product that stories and conversations do. Also, if our work is driven by a list of product attributes, when we are done the best we can say is that the delivered product possesses the attributes on the list. This is not the same as saying the delivered product meets all of a user’s goals.
第 13 章，为什么要使用用户故事？
Chapter 13, Why User Stories?
13.1使用用户故事表达需求的四个充分理由是什么？
13.1 What are four good reasons for using user stories to express requirements?
答：用户故事强调口头交流，每个人都能理解，适合规划，支持迭代开发，鼓励推迟细节，支持机会主义设计，鼓励参与式设计，建立默会知识。
Answer: User stories emphasize verbal communication, are comprehensible by everyone, are the right size for planning, support iterative development, encourage deferring detail, support opportunistic design, encourage participatory design and build up tacit knowledge.
13.2使用用户故事的两个缺点是什么？
13.2 What can be two drawbacks to using user stories?
回答：在大型项目中，很难组织成百上千的故事；为了可追溯性，可能需要用额外的文件来扩充故事；而且，虽然通过面对面的交流可以很好地提高隐性知识，但对话的规模不足以完全取代大型项目中的书面文件。
Answer: On large projects it can be difficult to keep hundreds or thousands of stories organized; stories may need to be augmented with additional documents for traceability; and, while great at improving tacit knowledge through face-to-face communication, conversations do not scale adequately to entirely replace written documents on large projects.
13.3参与式设计和实证设计之间的主要区别是什么？
13.3 What is the key difference between participatory and empirical design?
回答：在参与式设计中，系统的预期用户成为设计该系统行为的团队的一部分。在经验上在设计过程中，软件设计者研究或观察目标用户，然后由他们做出所有设计决策。
Answer: In participatory design, the intended users of a system become a part of the team designing the behavior of that system. In empirical design, the intended users are instead studied or observed by the designers of the software, who then make all of the design decisions.
13.4要求声明“所有多页报告都应编号”有什么问题？
13.4 What is wrong with the requirements statement, “All multipage reports should be numbered”?
回答：不清楚“应该编号”是什么意思。这是否意味着程序员应该编写此功能但不必编写代码？这是否意味着如果页面上有空间就应该对页面进行编号？
Answer: It is unclear what “should be numbered” means. Does this mean that the programmers should code this functionality but don’t have to? Does it mean pages should be numbered if there’s room on the page?
第14章，故事气味目录
Chapter 14, A Catalog of Story Smells
14.1如果团队一直发现难以计划下一次迭代，您应该怎么办？
14.1 What should you do if the team is consistently finding it difficult to plan the next iteration?
回答：可能还有其他原因，但您应该考虑是否太多的故事是相互依存的，或者是太小还是太大。
Answer: There could be other reasons but you should consider whether too many stories are interdependent, or are too small or too large.
14.2如果团队一直没有足够的空间来写故事卡，他们应该怎么办？
14.2 What should the team do if they are consistently running out of room to write on the story cards?
答案：他们应该使用较小的卡片来执行将细节保留在故事描述之外的纪律。
Answer: They should use smaller cards to enforce the discipline of keeping details out of the story descriptions.
14.3什么会导致客户难以确定故事的优先级？
14.3 What could cause the customer to have a difficult time prioritizing stories?
回答：故事的大小可能不正确（太大或太小），或者故事可能无法清楚地向用户或客户表达价值。
Answer: The stories may be the wrong size (either too large or too small) or the stories may not clearly express value to users or customers.
14.4你怎么知道你是否拆分了太多的故事？
14.4 How do you know if you are splitting too many stories?
答：你必须依靠你的直觉。故事经常被合理地分割，因为它们一开始就被故意写成史诗，或者因为它们太大而无法进行迭代。如果您发现自己经常因为其他原因拆分故事，那么您可能做得太频繁了。
Answer: You have to rely on your gut feel. Stories are often and legitimately split because they were intentionally written as epics to start with, or because they are too big to fit into an iteration. If you find yourself frequently splitting stories for other reasons, you may be doing it too often.
第 15 章，将故事与 Scrum 结合使用
Chapter 15, Using Stories with Scrum
15.1描述增量过程和迭代过程之间的区别。
15.1 Describe the differences between an incremental and an iterative process.
回答：迭代过程是通过连续改进取得进步的过程。增量过程是一种软件构建和交付的过程。
Answer: An iterative process is one that makes progress through successive refinement. An incremental process is one in which software is built and delivered in pieces.
15.2 product backlog和sprint backlog有什么关系？
15.2 What is the relationship between the product backlog and the sprint backlog?
答案：项目在冲刺开始时从产品待办列表移至冲刺待办列表。
Answer: Items are moved from the product backlog to the sprint backlog at the start of a sprint.
15.3潜在可交付产品增量是什么意思？
15.3 What is meant by a potentially shippable product increment?
答案：在每个冲刺结束时，Scrum 团队负责创建潜在可交付的产品增量。这意味着该软件经过编码、测试并可以提供给用户。
Answer: By the end of each sprint a Scrum team is responsible for creating a potentially shippable product increment. This means the software is coded, tested and could be given to users.
15.4谁负责确定工作的优先级和选择团队在冲刺期间执行的工作？
15.4 Who is responsible for prioritizing work and for selecting the work the team will perform during a sprint?
回答：产品负责人确定工作的优先级，但团队选择他们将在冲刺期间执行的工作。自然地，他们应该从最优先的项目中进行选择。
Answer: The Product Owner prioritizes the work but the team selects the work they will perform during a sprint. Naturally they are expected to select from among the top priority items.
15.5每个团队成员在每日站会上回答了哪些问题？
15.5 What questions are answered by each team member at the daily scrum?
回答：你昨天做了什么？你今天会做什么？你有什么障碍？
Answer: What did you do yesterday? What will you do today? What is in your way?
第 16 章，附加主题
Chapter 16, Additional Topics
16.1你应该如何处理系统扩展到 1000 个并发用户使用的需求？
16.1 How should you handle a requirement for a system to scale up to use by 1,000 concurrent users?
回答：你应该把它写成一个约束，然后用适当的测试来补充它。根据系统的不同，您可能希望从一次迭代中 100 个并发用户的测试开始，然后在多次迭代中逐渐增加到 1,000 个用户。
Answer: You should write this as a constraint and then supplement it with appropriate tests. Depending on the system, you may want to start with a test for 100 concurrent users in one iteration and progressively increase that to 1,000 users over a number of iterations.
16.2你更喜欢在笔记卡上还是在软件系统中写故事？捍卫你的答案。
16.2 Do you prefer to write stories on note cards or in a software system? Defend your answer.
答案：记事卡的低技术简单性使其成为许多项目的理想选择。卡片还提供有限的空间，这有助于让故事保持简短。因为它们可以很容易地在桌子或墙上随意移动，所以它们非常适合规划。但是，不在同一地点或具有严格的可追溯性要求的团队可能更愿意使用软件。
Answer: The low-tech simplicity of note cards make them ideal for many projects. Cards also offer a limited amount of space, which helps keep stories brief. Because they can be easily shuffled about on a table or wall they are ideal for planning. However, a team that is not collocated or has stringent traceability requirements might prefer to work with software.
16.3迭代过程对应用程序的用户界面有什么影响？
16.3 What impact does an iterative process have on the user interface of an application?
答：系统的迭代细化会使用户更难学习系统。当菜单系统发生变化或功能出现在不同的地方时，用户必须重新学习他们的系统。
Answer: Iterative refinement of the system can make it harder for users to learn the system. When menu systems change or features appear in different places, users must relearn they system.
16.4给出一些系统示例，这些系统可以从比敏捷项目中通常给出的用户界面更多的前期考虑中获益。
16.4 Give some examples of systems that could benefit from more upfront consideration of the user interface than is typically given on an agile project.
回答：可以有很多例子，但这里有一些：
Answer: There can be many examples but here are a few:
• 主要通过易用性在成熟行业中竞争的商业产品
• a commercial product that competes in a mature industry primarily through ease of use
• 针对新手用户的软件
• software aimed at novice users
• 很少使用但会频繁使用的软件（例如所得税准备）
• software that will be used rarely but for intense periods (such as for income tax preparation)
• software for low vision users or users with a movement disorder
参考
References
书籍和文章
Books and Articles
Adolph、Steve、Paul Bramble 等人。有效用例的模式。马萨诸塞州雷丁：Addison-Wesley，2002 年。
Adolph, Steve, Paul Bramble, et al. Patterns for Effective Use Cases. Reading, Mass.: Addison-Wesley, 2002.
Antón、Annie I. 和 Colin Potts。“The Use of Goals to Surface Requirements for Evolving Systems”，第 20 届国际软件工程会议论文集 (ICSE 98)，1998 年 4 月：157-166。
Antón, Annie I., and Colin Potts. “The Use of Goals to Surface Requirements for Evolving Systems,” in Proceedings of the 20th International Conference on Software Engineering (ICSE 98), April 1998: 157–166.
阿斯特尔斯，戴夫。测试驱动开发：实用指南。新泽西州上马鞍河：Prentice Hall，2003 年。
Astels, Dave. Test Driven Development: A practical guide. Upper Saddle River, N.J.: Prentice Hall, 2003.
贝克，肯特。极限编程详解：拥抱变化。波士顿：Addison-Wesley，2000。
Beck, Kent. Extreme Programming Explained: Embrace change. Boston: Addison-Wesley, 2000.
贝克，肯特。测试驱动开发。马萨诸塞州雷丁：Addison-Wesley，2003 年。
Beck, Kent. Test Driven Development. Reading, Mass.: Addison-Wesley, 2003.
贝克、肯特和马丁·福勒。规划极限编程。马萨诸塞州雷丁：Addison-Wesley，2000 年。
Beck, Kent, and Martin Fowler. Planning Extreme Programming. Reading, Mass.: Addison-Wesley, 2000.
比德尔、迈克等人。“SCRUM：一种用于高效软件开发的模式语言。” 在尼尔哈里森等人。（编辑），程序设计的模式语言 4。Addison-Wesley：1999 年，第 637–651 页。
Beedle, Mike, et al. “SCRUM: A Pattern Language for Hyperproductive Software Development.” In Neil Harrison et al. (Eds.), Pattern Languages of Program Design 4. Addison-Wesley: 1999, pp. 637–651.
伯姆，巴里。“发展和增强的螺旋模型。” IEEE 计算机 28，没有。5（1988 年 5 月）：61-72。
Boehm, Barry. “A Spiral Model of Development and Enhancement.” IEEE Computer 28, no. 5 (May 1988): 61–72.
伯姆，巴里。软件工程经济学。新泽西州恩格尔伍德悬崖：Prentice-Hall，1981 年。
Boehm, Barry. Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-Hall, 1981.
Bower、GH、JB Black 和 TJ Turner。“文本内存中的脚本。” 认知心理学 11 (1979)：177–220。
Bower, G. H., J. B. Black, and T. J. Turner. “Scripts in Memory for Text.” Cognitive Psychology 11 (1979): 177–220.
Carroll, John M. “使用设计表示法”。 ACM 通讯 37，没有。12（1994 年 12 月）：29-35。
Carroll, John M. “Making Use a Design Representation.” Communications of the ACM 37, no. 12 (December 1994): 29–35.
Carroll, John M.使用：人机交互中基于场景的设计。马萨诸塞州剑桥市：麻省理工学院出版社，2000 年。
Carroll, John M. Making Use: Scenario-based design in human-computer interaction. Cambridge, Mass.: The MIT Press, 2000.
Carroll, John M. “利用不仅仅是任务分析的问题。” 与计算机交互 14，第 5 (2002): 619–627。
Carroll, John M. “Making use is more than a matter of task analysis.” Interacting with Computers 14, no. 5 (2002): 619–627.
Carroll, John M.、Mary Beth Rosson、George Chin Jr. 和 Jürgen Koenemann。“基于场景的设计中的需求开发”。 IEEE 软件工程交易 24，没有。12（1998 年 12 月）：1156–1170。
Carroll, John M., Mary Beth Rosson, George Chin Jr., and Jürgen Koenemann. “Requirements Development in Scenario-Based Design.” IEEE Transactions on Software Engineering 24, no. 12 (December 1998): 1156–1170.
西里洛，弗朗切斯科。“XP：在后互联网时代提供竞争优势。” 在www.communications.xplabs.com/paper2001-3.html。XP 实验室，2001 年。
Cirillo, Francesco. “XP: Delivering the Competitive Edge in the Post-Internet Era.” At www.communications.xplabs.com/paper2001-3.html. XP Labs, 2001.
科伯恩，阿利斯泰尔。编写有效的用例。新泽西州上马鞍河：Addison-Wesley，2001 年。
Cockburn, Alistair. Writing Effective Use Cases. Upper Saddle River, N.J.: Addison-Wesley, 2001.
Cockburn、Alistair 和 Laurie L. Williams。“结对编程的成本和收益。” 在 Giancarlo Succi 和 Michele Marchesi（编辑）的《极限编程检查》中。新泽西州上马鞍河：Addison-Wesley，2001 年。
Cockburn, Alistair, and Laurie L. Williams. “The Costs and Benefits of Pair Programming.” In Giancarlo Succi and Michele Marchesi (Eds.), Extreme Programming Examined. Upper Saddle River, N.J.: Addison-Wesley, 2001.
科恩，迈克。“裁员的好处。” 软件测试和质量工程 5，没有。1（2003 年 1 月）：18-21。
Cohn, Mike. “The Upside of Downsizing.” Software Test and Quality Engineering 5, no. 1 (January 2003): 18–21.
康斯坦丁，拉里。“偷工减料。” 软件开发（2000 年 2 月）。
Constantine, Larry. “Cutting Corners.” Software Development (February 2000).
康斯坦丁，拉里。“过程敏捷性和软件可用性：走向轻量级和以使用为中心的设计。” 信息时代（2002 年 8 月至 9 月）。
Constantine, Larry. “Process Agility and Software Usability: Toward lightweight and usage-centered design.” Information Age (August-September 2002).
Constantine、Larry L. 和 Lucy AD Lockwood。使用软件：以使用为中心的设计模型和方法的实用指南。马萨诸塞州雷丁：Addison-Wesley，1999 年。
Constantine, Larry L., and Lucy A.D. Lockwood. Software for Use: A practical guide to the models and methods of usage-centered design. Reading, Mass.: Addison-Wesley, 1999.
Constantine、Larry L. 和 Lucy AD Lockwood。“Web 应用程序的以使用为中心的工程。” IEEE 软件 19，没有。2（2002 年 3 月/4 月）：42-50。
Constantine, Larry L., and Lucy A.D. Lockwood. “Usage-Centered Engineering for Web Applications.” IEEE Software 19, no. 2 (March/April 2002): 42–50.
库珀，艾伦。囚犯正在经营收容所。印第安纳波利斯：SAMS，1999 年。
Cooper, Alan. The Inmates Are Running the Asylum. Indianapolis: SAMS, 1999.
Cusumano、Michael A. 和 Richard W. Selby。微软的秘密：世界上最强大的软件公司如何创造技术、塑造市场和管理人员。纽约：自由出版社，1995 年。
Cusumano, Michael A., and Richard W. Selby. Microsoft Secrets: How the world’s most powerful software company creates technology, shapes markets, and manages people. New York: The Free Press, 1995.
戴维斯，雷切尔。“故事的力量。” XP 2001。撒丁岛，2001 年。
Davies, Rachel. “The Power of Stories.” XP 2001. Sardinia, 2001.
Djajadiningrat、JP、WW Gaver 和 JW Frens。“交互重新标记和极端字符：探索审美交互的方法。” 设计交互系统研讨会2000，2000：66-71。
Djajadiningrat, J. P., W. W. Gaver and J. W. Frens. “Interaction Relabelling and Extreme Characters: Methods for exploring aesthetic interactions.” Symposium on Designing Interactive Systems 2000, 2000: 66–71.
福勒，马丁。“万能的砰砰声。” 分布式计算（1997 年 11 月）。
Fowler, Martin. “The Almighty Thud.” Distributed Computing (November 1997).
福勒、马丁等人。重构：改进现有代码的设计，Reading，Mass.：Addison-Wesley，1999。
Fowler, Martin, et al. Refactoring: Improving the design of existing code, Reading, Mass.: Addison-Wesley, 1999.
吉尔布，汤姆。软件工程管理原理。马萨诸塞州雷丁：Addison-Wesley，1988 年。
Gilb, Tom. Principles of Software Engineering Management. Reading, Mass.: Addison-Wesley, 1988.
金东，雷蒙德。“设计设计过程：利用机会主义思想。” 人机交互 5 , 1990.
Guindon, Raymonde. “Designing the Design Process: Exploiting opportunistic thoughts.” Human-Computer Interaction 5, 1990.
格鲁丁、乔纳森和约翰·普鲁伊特。“角色、参与式设计和产品开发：参与的基础设施。” 在 Thomas Binder、Judith Gregory 和 Ina Wagner（编辑），参与和设计：探究协作设计工作的政治、背景和实践，参与式设计会议论文集 2002：2002：144-161。
Grudin, Jonathan, and John Pruitt. “Personas, Participatory Design and Product Development: An Infrastructure for Engagement.” In Thomas Binder, Judith Gregory, and Ina Wagner (Eds.), Participation and Design: Inquiring into the politics, contexts and practices of collaborative design work, Proceedings of the Participatory Design Conference 2002: 2002: 144–161.
IEEE 计算机协会。IEEE 软件需求规范推荐实践。纽约，1998 年。
IEEE Computer Society. IEEE Recommended Practice for Software Requirements Specifications. New York, 1998.
雅各布森，伊瓦尔。面向对象的软件工程。新泽西州上马鞍河：Addison-Wesley，1992 年。
Jacobson, Ivar. Object-Oriented Software Engineering. Upper Saddle River, N.J.: Addison-Wesley, 1992.
Jacobson、Ivar、Grady Booch 和 James Rumbaugh。统一软件开发过程。马萨诸塞州雷丁：Addison-Wesley，1999 年。
Jacobson, Ivar, Grady Booch, and James Rumbaugh. The Unified Software Development Process. Reading, Mass.: Addison-Wesley, 1999.
杰弗里斯，罗恩。“基本 XP：卡片、对话和确认。” XP 杂志（2001 年 8 月 30 日）。
Jeffries, Ron. “Essential XP: Card, Conversation, and Confirmation.” XP Magazine (August 30, 2001).
Jeffries、Ron、Ann Anderson 和 Chet Hendrickson。安装了极限编程。波士顿：Addison-Wesley，2000。
Jeffries, Ron, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed. Boston: Addison-Wesley, 2000.
Kensing、Finn 和 Andreas Munk-Madsen。“PD：工具箱中的结构。” ACM 36 的通讯，没有。6（1993 年 6 月）：78-85。
Kensing, Finn, and Andreas Munk-Madsen. “PD: Structure in the Toolbox.” Communications of the ACM 36, no. 6 (June 1993): 78–85.
Kovitz, Ben L.实用软件要求：内容和风格手册。康涅狄格州格林威治：曼宁，1999 年。
Kovitz, Ben L. Practical Software Requirements: A manual of content and style. Greenwich, Conn.: Manning, 1999.
Kuhn、Sarah 和 Michael J. Muller。“参与式设计专题介绍。” ACM 通讯 36，没有。6（1993 年 6 月）：24-28。
Kuhn, Sarah, and Michael J. Muller. “Introduction to the Special Section on Participatory Design.” Communications of the ACM 36, no. 6 (June 1993): 24–28.
劳森，索伦。软件要求：风格和技术。伦敦：Addison-Wesley，2002 年。
Lauesen, Soren. Software Requirements: Styles and techniques. London: Addison-Wesley, 2002.
伦德、埃里克和马丁桑德伯格。“使用极限编程的时间约束需求工程：经验报告。” 在 Armin Eberlein 和 Julio CesarSampaiodoPrado Leite（编辑），国际时间约束需求工程研讨会论文集，2002 年。
Lundh, Erik, and Martin Sandberg. “Time Constrained Requirements Engineering with Extreme Programming: An experience report.” In Armin Eberlein and Julio CesarSampaiodoPrado Leite (Eds.), Proceedings of the International Workshop on Time Constrained Requirements Engineering, 2002.
Newkirk、James 和 Robert C. Martin。实践中的极限编程。新泽西州上马鞍河：Addison-Wesley，2001 年。
Newkirk, James, and Robert C. Martin. Extreme Programming in Practice. Upper Saddle River, N.J.: Addison-Wesley, 2001.
Parnas、David L. 和 Paul C. Clements。“一个理性的设计过程：如何以及为什么要伪造它。” IEEE 软件工程汇刊 12，没有。2（1986 年 2 月）：251-7。
Parnas, David L., and Paul C. Clements. “A Rational Design Process: How and why to fake it.” IEEE Transactions on Software Engineering 12, no. 2 (February 1986): 251–7.
巴顿，杰夫。“击中目标：将交互设计添加到敏捷软件开发中。” 面向对象编程系统语言和应用会议 (OOPSLA 2002)。纽约：ACM 出版社，2002 年。
Patton, Jeff. “Hitting the Target: Adding interaction design to agile software development.” Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA 2002). New York: ACM Press, 2002.
波彭迪克，汤姆。敏捷客户的工具包。在 Larry L. Constantine（主编），forUSE 2003 会议记录中。马萨诸塞州罗利：Ampersand 出版社：2003 年。
Poppendieck, Tom. The Agile Customer’s Toolkit. In Larry L. Constantine (Ed.), Proceedings of forUSE 2003. Rowley, Mass.: Ampersand Press: 2003.
Potts、Colin、Kenji Takahashi 和 Annie I. Antón。“基于查询的需求分析。” IEEE 软件 11，没有。2（1994 年 3 月/4 月）：21-32。
Potts, Colin, Kenji Takahashi, and Annie I. Antón. “Inquiry-Based Requirements Analysis.” IEEE Software 11, no. 2 (March/April 1994): 21–32.
罗伯逊、苏珊娜和詹姆斯·罗伯逊。掌握需求过程。马萨诸塞州雷丁：Addison-Wesley，1999 年。
Robertson, Suzanne and James Robertson. Mastering the Requirements Process. Reading, Mass.: Addison-Wesley, 1999.
舒勒、道格拉斯和 Aki Namioka（编辑）。参与式设计：原则和实践。新泽西州希尔斯代尔：埃尔鲍姆出版社，1993 年。
Schuler, Douglas, and Aki Namioka (Eds.). Participatory Design: Principles and practices. Hillsdale, N.J.: Erlbaum, 1993.
施瓦伯、肯和迈克·比德尔。使用 Scrum 进行敏捷软件开发。新泽西州上马鞍河：Prentice Hall，2002 年。
Schwaber, Ken, and Mike Beedle. Agile Software Development with Scrum. Upper Saddle River, N.J.: Prentice Hall, 2002.
斯台普顿，詹妮弗。DSDM：以业务为中心的开发。马萨诸塞州雷丁：Addison-Wesley，2003 年。
Stapleton, Jennifer. DSDM: Business Focused Development. Reading, Mass.: Addison-Wesley, 2003.
Swartout、William 和 Robert Balzer。“关于规范和实施的不可避免的交织。” ACM 25的通讯，没有。7（1982 年 7 月）：438–440。
Swartout, William, and Robert Balzer. “On the Inevitable Intertwining of Specification and Implementation.” Communications of the ACM 25, no. 7 (July 1982): 438–440.
瓦格纳，拉里。“极端需求工程。” Cutter IT Journal 14，第1 期 12（2001 年 12 月）。
Wagner, Larry. “Extreme Requirements Engineering.” Cutter IT Journal 14, no. 12 (December 2001).
Wake, William C.探索极限编程。马萨诸塞州雷丁：Addison-Wesley，2002 年。
Wake, William C. Extreme Programming Explored. Reading, Mass: Addison-Wesley, 2002.
Wake, William C. “投资于好故事和 SMART 任务。” 在www.xp123.com 上，2003a。
Wake, William C. “INVEST in Good Stories, and SMART Tasks.” At www.xp123.com, 2003a.
Wake, William C.重构工作簿。马萨诸塞州雷丁：Addison-Wesley，2003b。
Wake, William C. Refactoring Workbook. Reading, Mass.: Addison-Wesley, 2003b.
Weidenhaupt、Klaus、Klaus Pohl、Matthias Jarke 和 Peter Haumer。“系统开发场景：当前实践。” IEEE 软件 15，没有。2（1998 年 3 月/4 月）：34–45。
Weidenhaupt, Klaus, Klaus Pohl, Matthias Jarke, and Peter Haumer. “Scenarios in System Development: Current practice.” IEEE Software 15, no. 2 (March/April 1998): 34–45.
Wiegers, Karl E.软件要求。华盛顿州雷德蒙德：微软出版社，1999 年。
Wiegers, Karl E. Software Requirements. Redmond, Wash.: Microsoft Press, 1999.
Williams、Marian G. 和 Vivienne Begg。“软件设计师和用户之间的翻译。” ACM 通讯 36，没有。6（1993 年 6 月）：102-3。
Williams, Marian G., and Vivienne Begg. “Translation between software designers and users.” Communications of the ACM 36, no. 6 (June 1993): 102–3.
网站
Websites
指数
Index
一种
A
验收测试，12–13、15、67–74 _ _
Acceptance testing, 12–13, 15, 67–74
客户责任，73
customer responsibilities, 73
测试的客户规范，69
customer specification of the tests, 69
开发者责任，73
developer responsibilities, 73
综合测试框架 (FIT)，70–71
Framework for Integrated Test (FIT), 70–71
南海岸航海用品（示例项目），223–230
South Coast Nautical Supplies (example project), 223–230
管理，227-228
administration, 227–228
买书，225-226
buying books, 225–226
约束测试，228-229
constraint testing, 228–229
最后的故事，229-230
final story, 229–230
搜索测试，223–224
search tests, 223–224
购物车测试，224–225
shopping cart tests, 224–225
用户帐户，226–227
user accounts, 226–227
测试作为流程的一部分，69–70
testing as part of the process, 69–70
测试类型，72
types of testing, 72
写作测试，12-13
writing tests, 12–13
编码前，68–69
before coding, 68–69
编写太多测试，70
writing too many tests, 70
账户，南海岸航海用品（示例项目），214-215
Accounts, South Coast Nautical Supplies (example project), 214–215
主动语态，写作，81
Active voice, writing in, 81
行政故事，南海岸航海用品（示例项目），205–206
Administration stories, South Coast Nautical Supplies (example project), 205–206
使用Scrum进行敏捷开发(Schwaber/Beedle)，165
Agile Development with Scrum (Schwaber/Beedle), 165
敏捷流程，111
Agile processes, 111
以使用为中心的敏捷设计，182
Agile usage-centered design, 182
安德森，安，233
Anderson, Ann, 233
Astels, 戴夫, 237
Astels, Dave, 237
乙
B
难闻的气味：
Bad smells:
客户责任，163
customer responsibilities, 163
客户不会撰写故事并确定故事的优先级，162
customer won’t write and prioritize the stories, 162
开发人员的责任，163
developer responsibilities, 163
镀金，158–159
goldplating, 158–159
太快包括用户界面细节，159–160
including user interface detail too soon, 159–160
相互依存的故事，157–158
interdependent stories, 157–158
优先考虑困难，161-162
prioritizing difficulties, 161–162
小故事，157
small stories, 157
拆分太多故事，160–161
splitting too many stories, 160–161
想得太远，160
thinking too far ahead, 160
太多的细节，159
too many details, 159
贝克, 肯特, 97 , 136 , 233–234 , 236 , 239
Beck, Kent, 97, 136, 233–234, 236, 239
Berczuk，史蒂夫，136
Berczuk, Steve, 136
BigMoneyJobs示例故事，4–6，23
BigMoneyJobs example story, 4–6, 23
黑色，JB，148
Black, J. B., 148
鲍尔, GH, 148
Bower, G. H., 148
头脑风暴：
Brainstorming:
初始用户角色集，33–34
initial set of user roles, 33–34
低保真原型，49
with low-fidelity prototyping, 49
C
C
捕获，43
Capture, 43
Card, 4 , 另见记事卡；故事卡
Card, 4, See also Note cards; Story cards
注释，6-7
annotations on, 6–7
写在背面，7
writing on the back of, 7
Carroll, John M., 135 , 141–142
Carroll, John M., 135, 141–142
中心极限定理，92
Central Limit Theorem, 92
认证，180
Certification, 180
改变优先级，110
Changing priorities, 110
克莱门茨，保罗 C.，151
Clements, Paul C., 151
ClickTactics，选择软件，180
ClickTactics, choosing software at, 180
封闭的故事，76-77
Closed stories, 76–77
科伯恩、阿利斯泰尔，137、140、150、237 _ _ _
Cockburn, Alistair, 137, 140, 150, 237
迈克·科恩，173 岁
Cohn, Mike, 173
并置团队，105
Collocated team, 105
颜色，185
Colors, 185
竞争分析，65
Competitive analysis, 65
复杂的故事，24-26
Complex stories, 24–26
分裂, 25
splitting, 25
复合故事，24-25
Compound stories, 24–25
分解, 25
disaggregating, 25
确认，4
Confirmation, 4
连接池，5
Connection pools, 5
一致的迭代，103
Consistent iterations, 103
康斯坦丁·拉里，31岁、59 岁、140岁、148岁、181–182岁
Constantine, Larry, 31, 59, 140, 148, 181–182
约束，例子，77-78
Constraints, examples of, 77–78
上下文无关的问题，46-47
Context-free questions, 46–47
艾伦·库珀，135 岁
Cooper, Alan, 135
企业桌面生产力软件，59
Corporate desktop productivity software, 59
成本和优先级，100
Cost, and priority, 100
可能具有的功能，发布计划，98–99
Could-have features, release plan, 98–99
信用卡有效期，71
Credit card validity, 71
客户责任：
Customer responsibilities:
难闻的气味，163
bad smells, 163
收集故事，53
gathering stories, 53
迭代计划，116
iteration planning, 116
发布计划，107
release planning, 107
用户代理，65
user proxies, 65
用户角色重塑，41
user role remodeling, 41
用户故事，估算，95
user stories, estimating, 95
速度，测量/监控，127
velocity, measuring/monitoring, 127
写故事，28
writing stories, 28
构成, 63–64
constituting, 63–64
故事写作者，9
story writing by, 9
客户，作为用户代理，65
Customers, as user proxies, 65
丁
D
每日燃尽图，123–126
Daily burndown chart, 123–126
决策，依据，4
Decision-making, basis of, 4
缺陷追踪器，179
Defect trackers, 179
故事之间的依赖关系，17-18
Dependencies between stories, 17–18
细节，5–7
Details, 5–7
开发团队-客户讨论，6-7
development team–customer discussions about, 6–7
作为测试，20
as tests, 20
细节太多，气味难闻，159
too many details, as bad smell, 159
过于详细的用户故事，19-20
user stories with too much detail, 19–20
开发人员职责：验收测试用户故事，73
Developer responsibilities: acceptance testing user stories, 73
难闻的气味，163
bad smells, 163
收集故事，53
gathering stories, 53
迭代计划，115
iteration planning, 115
发布计划，106
release planning, 106
用户代理，65
user proxies, 65
用户角色重塑，40
user role remodeling, 40
用户故事，155
user stories, 155
用户故事，估算，94
user stories, estimating, 94
速度，测量/监控，127
velocity, measuring/monitoring, 127
写故事，28
writing stories, 28
Diaspar 软件服务，181
Diaspar Software Services, 181
Disaggregation, 25, 94, 111–112
指南，112
guidelines, 112
领域知识，缺乏，23
Domain knowledge, lack of, 23
DSDM 和 MoSCoW 规则，98
DSDM, and MoSCoW rules, 98
DSDM：以业务为中心的开发(Stapleton)，98
DSDM: Business Focused Development (Stapleton), 98
乙
E
启发，43
Elicitation, 43
实证设计，152
Empirical design, 152
类别, 24
categories of, 24
基本用例，140
Essential use cases, 140
可估计的故事，22-23
Estimatable stories, 22–23
估计：
Estimating:
方法，88-90
approach, 88–90
作为一个团队，88
as a team, 88
三角测量估计，90-91
triangulating an estimate, 90–91
示例项目，请参阅南海岸航海用品（示例项目）：
Example project, See South Coast Nautical Supplies (example project):
示例用户故事，4-5
Example user story, 4–5
期望最大化，101
Expectation maximization, 101
额外的细节，19
Extra detail, 19
极端人物，39
Extreme characters, 39
极限编程解释：拥抱变化(Beck)，233
Extreme Programming Explained: Embrace Change (Beck), 233
Extreme Programming Explored (Wake), 17, 233
安装了极限编程（Jeffries、Anderson 和 Hendrickson），233
Extreme Programming Installed (Jeffries, Anderson, and Hendrickson), 233
极限编程 (XP), 8 , 22 , 88 , 179 , 233–243
Extreme Programming (XP), 8, 22, 88, 179, 233–243
教练，234
coach, 234
客户角色，233
customer role, 233
241-242的原则
principles of, 241–242
程序员角色，234
programmer role, 234
角色，233–234
roles, 233–234
团队, 26
teams, 26
十二种 XP 实践，234–240
twelve XP practices, 234–240
编码标准，239
coding standards, 239
持续集成，240
continuous integration, 240
比喻, 239
metaphor, 239
现场客户，240
on-site customer, 240
结对编程，237–238
pair programming, 237–238
规划游戏，235–236
Planning Game, 235–236
重构, 236
refactoring, 236
简单的设计, 239
simple design, 239
小版本，235
small releases, 235
可持续的步伐，238
sustainable pace, 238
团队代码所有权，238–239
team code ownership, 238–239
测试，236–237
testing, 236–237
值，240–241
values, 240–241
F
F
项目成功的关键因素，决定，64
Factors critical to project success, determining, 64
第一次迭代，9
First iteration, 9
综合测试框架 (FIT)，70–71
Framework for Integrated Test (FIT), 70–71
G
G
收集故事，43-52
Gathering stories, 43–52
客户责任，53
customer responsibilities, 53
开发者责任，53
developer responsibilities, 53
引出和捕获，43-44
elicitation and capture, 43–44
观察，48-49
observation, 48–49
问卷，47-48
questionnaires, 47–48
故事写作工作坊，49-52
story-writing workshops, 49–52
技巧, 45
techniques, 45
用户访谈，45–47
user interviews, 45–47
以不同的细节层次写故事，44-45
write stories at different levels of detail, 44–45
吉尔布，汤姆，101
Gilb, Tom, 101
目标故事，从75开始
Goal stories, starting with, 75
镀金，158–159
Goldplating, 158–159
例如，158
example of, 158
好故事：
Good stories:
属性, 17
attributes of, 17
指南，75-83
guidelines for, 75–83
主动语态，写作，81
active voice, writing in, 81
封闭的故事，76-77
closed stories, 76–77
客户作为故事的作者，81-82
customer as writer of the stories, 81–82
包括故事中的用户角色，80-81
including user roles in the stories, 80–81
对卡片施加限制，77–78
putting constraints on cards, 77–78
调整故事大小，78–79
sizing the story, 78–79
故事卡，编号，82
story cards, numbering, 82
用户界面，79–80
user interface, 79–80
使用其他格式，80
using other formats, 80
为一个用户写作，81
writing for one user, 81
写作指南：
guidelines for writing:
目标故事，从76开始
goal stories, starting with, 76
拆分故事
splitting stories
格伦宁，詹姆斯，137
Grenning, James, 137
Guindon, 雷蒙德, 151
Guindon, Raymonde, 151
H
H
亨德里克森，切特，233
Hendrickson, Chet, 233
高度依赖的故事，17-18
Highly dependent stories, 17–18
高优先级故事，183
High-priority stories, 183
历史值和初始速度，104
Historical values, and initial velocity, 104
我
I
IEEE 830：
IEEE 830:
与用户故事相比，133–136
compared to user stories, 133–136
要求，135–136
requirements, 135–136
增量过程：
Incremental process:
定义，166
defined, 166
Scrum 作为，166
Scrum as, 166
独立故事，17–18
Independent stories, 17–18
个人所有权，238–239
Individual ownership, 238–239
基础设施需求和需求优先顺序，101-103
Infrastructural needs, and prioritization of needs, 101–103
最初的故事集，209
Initial collection of stories, 209
初始用户角色集：
Initial set of user roles:
头脑风暴，33-34
brainstorming, 33–34
组织，34-35
organizing, 34–35
最初的故事，9
Initial stories, 9
初始速度，104–105
Initial velocity, 104–105
囚犯正在收容所，（库珀），135
Inmates Are Running the Asylum, The (Cooper), 135
电气和电子工程师协会 (IEEE)，133
Institute of Electrical and Electronics Engineers (IEEE), 133
相互依存的故事，难闻的气味，157–158
Interdependent stories, bad smells, 157–158
ISO（国际标准化组织），180
ISO (International Organization for Standardization), 180
迭代燃尽图，121–123
Iteration burndown charts, 121–123
图表大小，126
chart size, 126
每日燃尽图，123–125
daily burndown chart, 123–125
的用处，122
usefulness of, 122
迭代长度，选择，103
Iteration length, selecting, 103
Iteration planning, 10–12, 109–116
承担责任，113
accepting responsibility, 113
客户责任，116
customer responsibilities, 116
开发者责任，115
developer responsibilities, 115
分解为任务，111-112
disaggregating into tasks, 111–112
讨论故事，110
discussing the stories, 110
估计和确认，113-114
estimation and confirmation, 113–114
迭代计划会议的一般活动顺序，109
general sequence of activities for iterative planning meeting, 109
迭代，9-10
Iterations, 9–10
迭代开发和用户故事，149–150
Iterative development, and user stories, 149–150
迭代过程，14
Iterative process, 14
定义，165
defined, 165
Scrum 作为，165–166
Scrum as, 165–166
杰
J
伊瓦尔·雅各布森，137
Jacobson, Ivar, 137
联合应用程序设计 (JAD) 会议，49
Joint Application Design (JAD) sessions, 49
钾
K
克里夫斯基，约书亚，87岁
Kerievsky, Joshua, 87
萨拉·库恩，152 岁
Kuhn, Sarah, 152
大号
L
大故事，暂时跳过，11-12
Large stories, temporarily skipping, 11–12
洛克伍德、露西，31岁、59 岁、140岁、148岁、182岁
Lockwood, Lucy, 31, 59, 140, 148, 182
低保真原型，49–50
Low-fidelity prototype, 49–50
扔掉，51
throwing away, 51
米
M
为你疯狂， 89 岁
Mad About You, 89
营销组，64
Marketing group, 64
马丁·迈卡，71 岁
Martin, Micah, 71
混合优先级，100–101
Mixed priorities, 100–101
莫斯科规则，98
MoSCoW rules, 98
米勒·迈克尔·J.，152
Muller, Michael J., 152
多用户代理，使用，65
Multiple user proxies, using, 65
必备功能，发布计划，98
Must-have features, release plan, 98
否
N
波冈亚纪，152
Namioka, Aki, 152
可协商的故事，18-19
Negotiable stories, 18–19
纽柯克，詹姆斯，77 岁
Newkirk, James, 77
非功能性需求：
Non-functional requirements:
准确性，178
accuracy, 178
容量, 179
capacity, 179
作为对系统行为的约束，177-179
as constraints on system behavior, 177–179
处理，177–179
handling, 177–179
互操作性，179
interoperability, 179
可维护性，179
maintainability, 179
性能，178
performance, 178
便携性，179
portability, 179
可重用性，178
reusability, 178
类型，177–178
types of, 177–178
记事卡，4
Note cards, 4
的颜色，185
colors of, 185
179–180的限制
limitations of, 179–180
注意，故事卡，7
Note, story card with, 7
欧
O
观察，48-49
Observation, 48–49
现场用户，39–40
On-site users, 39–40
开放式问题，46–47
Open-ended questions, 46–47
P
P
Pair programming, 92–93, 237–238
大卫·L·帕纳斯 (Parnas)，151
Parnas, David L., 151
参与式设计，152
Participatory design, 152
性能测试，72
Performance testing, 72
个人数字助理 (PDA) 掌上电脑，39
Personal digital assistant (PDA) handheld computer, 39
角色，38–39
Personas, 38–39
南海岸航海用品（示例项目），197–198
South Coast Nautical Supplies (example project), 197–198
计划速度，119–120
Planned velocity, 119–120
规划发布，97–107
Planning releases, 97–107
和迭代，10-12
and iterations, 10–12
定位用户角色卡，193
Positioning user role cards, 193
潜在可交付产品增量，170
Potentially shippable product increment, 170
精度和故事大小，93
Precision, and story size, 93
规定流程，44
Prescriptive processes, 44
优先事项，不断变化，110
Priorities, changing, 110
优先报道，98-101
Prioritizing stories, 98–101
客户难以确定优先级，161–162
customer has trouble prioritizing, 161–162
高级故事，183
high-level stories, 183
基础设施需求，101-103
infrastructural needs, 101–103
初始速度，104–105
initial velocity, 104–105
迭代长度，选择，103
iteration length, selecting, 103
混合优先级，100–101
mixed priorities, 100–101
冒险故事，101
risky stories, 101
从故事点到预期持续时间，103
from story points to expected duration, 103
过程，8–10
Process, 8–10
样品清单，168
sample list, 168
和用户故事，173
and user stories, 173
产品开发路线图，97
Product development roadmap, 97
产品负责人，167
Product owner, 167
项目负责人，识别，64
Project champion, identifying, 64
项目失败，3
Project failures, 3
购买者，用户和20-21之间的区别
Purchaser, distinction between user and, 20–21
问
Q
问卷，47-48
Questionnaires, 47–48
R
R
Rainsberger, JB, 181
Rainsberger, J. B., 181
重构工作簿（Wake），17
Refactoring Workbook (Wake), 17
可能具有的特征，98–99
could-have features, 98–99
创造，105–106
creating, 105–106
客户责任，107
customer responsibilities, 107
开发人员的责任，106
developer responsibilities, 106
启动, 97
initiating, 97
莫斯科规则，98
MoSCoW rules, 98
必备功能, 98
must-have features, 98
prioritizing stories, 10, 98–101
过于相信，106
putting too much faith in, 106
发布日期, 98
release date, 98
应具备的功能，98–99
should-have features, 98–99
南海岸航海用品（示例项目），219–222
South Coast Nautical Supplies (example project), 219–222
完成的计划，221-222
finished plan, 221–222
没有特征，98–99
won’t have features, 98–99
发布、规划，9-10
Releases, planning, 9–10
提醒，故事卡，18-20
Reminders, story cards as, 18–20
“需求工程”工作，160
“Requirements engineering” efforts, 160
保留用户故事，184–185
Retaining user stories, 184–185
冒险故事，101
Risky stories, 101
角色属性，36-37
Role attribute, 36–37
角色卡，33
Role cards, 33
角色建模步骤，33-37
Role modeling steps, 33–37
小号
S
销售人员，64 岁
Salespersons, 64
场景, 137
Scenarios, 137
与用户故事相比，141–142
compared to user stories, 141–142
道格拉斯·舒勒，152 岁
Schuler, Douglas, 152
肯·施瓦伯，165–166年
Schwaber, Ken, 165–166
敏捷，9
Scrum, 9
添加故事，173–174
adding stories to, 173–174
基础知识, 166
basics of, 166
作为迭代和增量过程，165–166
as both iterative and incremental process, 165–166
案例研究，174–175
case study, 174–175
169的主要规则
main rules of, 169
Scrum 团队，166–167
Scrum team, 166–167
冲刺计划会议，168–169
sprint planning meeting, 168–169
冲刺审查会议，169，170–171
sprint review meeting, 169, 170–171
使用故事，165–176
using stories with, 165–176
ScrumMaster ，167-168，170-172 _
选择范围管理器，179
Select Scope Manager, 179
短迭代，103
Short iterations, 103
应有的功能，发布计划，98–99
Should-have features, release plan, 98–99
小故事，难闻的气味，157
Small stories, bad smells, 157
软件配置管理模式(Berczuk)，136
Software Configuration Management Patterns (Berczuk), 136
软件开发项目，预测，3
Software development projects, predicting, 3
使用软件（Constantine 和 Lockwood），311
Software for Use (Constantine and Lockwood), 311
软件需求，作为通信问题，3
Software requirements, as a communication problem, 3
Software system, developer responsibilities, 186, 187
整理故事，99
Sorting stories, 99
南海岸航海用品（示例项目）：
South Coast Nautical Supplies (example project):
验收测试，223–230
acceptance tests, 223–230
管理，227-228
administration, 227–228
买书，225-226
buying books, 225–226
约束测试，228-229
constraint testing, 228–229
搜索测试，223–224
search tests, 223–224
购物车测试，224–225
shopping cart tests, 224–225
用户帐户，226–227
user accounts, 226–227
帐户，214-215
accounts, 214–215
行政故事，205–206
administration stories, 205–206
高级搜索，212–213
advanced search, 212–213
故事和估计的完整列表，216-217
complete list of stories and estimates, 216–217
巩固和缩小，193-195
consolidating and narrowing, 193–195
定义，191
defined, 191
估计故事，209-217
estimating the stories, 209–217
完成估算，215
finishing the estimates, 215
确定初始角色，192
identifying initial roles, 192
识别客户，191-192
identifying the customer, 191–192
角色，添加，197–198
personas, adding, 197–198
优先考虑故事，220-221
prioritizing the stories, 220–221
评级和审查，213-214
rating and reviewing, 213–214
发布计划，219–222
release plan, 219–222
完成，221–222
finished, 221–222
非航海礼品买家的故事，204
stories for a Non–Sailing Gift Buyer, 204
新手水手的故事，203
stories for a novice sailor, 203
报告查看者的故事，204–205
stories for a Report Viewer, 204–205
罗恩船长的故事，202–203
stories for Captain Ron, 202–203
特蕾莎的故事，199-202
stories for Teresa, 199–202
用户角色建模，195–197
user role modeling, 195–197
用户角色，191–198
user roles, 191–198
速度，估计，219
velocity, estimating, 219
斯派克，22岁
Spike, 22
进行不同的迭代，26
putting in a different iteration, 26
螺旋模型（Boehm），101
Spiral model (Boehm), 101
Splitting stories, 18, 23, 24–26, 75–76
拆分太多故事，如难闻的气味，160–161
splitting too many stories, as bad smell, 160–161
Sprint积压，166–167，170
冲刺目标，168
Sprint goal, 168
Sprint 计划会议，168–170
Sprint planning meeting, 168–170
用户故事，173–174
user stories in, 173–174
Sprint回顾会议，169，170–171，174 _
Sprint review meeting, 169, 170–171, 174
用户故事，174
user stories in, 174
短跑，166
Sprints, 166
詹妮弗·斯特普尔顿，98 岁
Stapleton, Jennifer, 98
故事卡：
Story cards:
定义, 18
defined, 18
179–180的限制
limitations of, 179–180
的主要目的, 82
main purpose of, 82
编号，82
numbering, 82
在背面写笔记，67
writing notes on the back of, 67
写在背面，7
writing on the back of, 7
背面写测试，13
writing test on the back of, 13
故事成本，10-11
Story cost, 10–11
故事点，87-88，91-92，94 _ _
Story points, 87–88, 91–92, 94
故事大小，23–27
Story size, 23–27
和精度，93
and precision, 93
故事气味，见恶臭：
Story smells, see Bad smells:
故事写作过程，8-10
Story writing process, 8–10
最初的故事，9
initial stories, 9
故事驱动的项目、过程，8-10
Story-driven projects, process, 8–10
故事写作工作坊，49-52
Story-writing workshops, 49–52
贡献者，52
contributors of, 52
重点，51-52
focus of, 51–52
压力测试，72
Stress testing, 72
调查，46
Surveys, 46
系统角色，35
System roles, 35
吨
T
技术支持人员，61人
Technical support personnel, 61
测试说明，7–8
Test descriptions, 7–8
可测试的故事，27
Testable stories, 27
测试驱动开发，237
Test-driven development, 237
测试：
Testing:
对于错误，72
for bugs, 72
综合测试框架 (FIT)，70–71
Framework for Integrated Test (FIT), 70–71
性能，72
performance, 72
压力，72
stress, 72
作为一个两步过程，67
as a two–step process, 67
可用性，72
usability, 72
用户界面，72
user interface, 72
测试，编码前编写，68–69
Tests, writing before coding, 68–69
主题, 97
Themes, 97
时间盒，22
Timebox, 22
时间紧迫的项目和推迟的细节，150
Time–constrained projects, and deferred detail, 150
运动鞋，61 岁
Trainers, 61
培训师和技术支持人员，作为用户代理，65
Trainers and technical support personnel, as user proxies, 65
拖网捕鱼的要求，43-44
Trawling for requirements, 43–44
TJ 特纳，148 岁
Turner, T. J., 148
十二种 XP 实践，234–240
Twelve XP practices, 234–240
ü
U
无法检验的故事，27
Untestable stories, 27
可用性测试，72
Usability testing, 72
用例简介，140
Use case briefs, 140
用户，购买者和20–21之间的区别
User, distinction between purchaser and, 20–21
用户界面指南，80
User interface guidelines, 80
用户界面测试，72
User interface testing, 72
用户界面 (UI)：
User interface (UI):
细节，包括过早，159–160
details, including too soon, 159–160
写二，183
writing two, 183
用户访谈，45–47
User Interviews, 45–47
开放式和上下文无关的问题，46-47
open-ended and contextfree questions, 46–47
用户代理，55–66
User proxies, 55–66
客户责任，65
customer responsibilities, 65
顾客，59-60 岁
customers, 59–60
开发者责任，65
developer responsibilities, 65
开发经理，57 岁
development manager, 57
领域专家，58-59
domain experts, 58–59
前用户，59
former users, 59
营销组，59
marketing group, 59
销售人员，57–58 岁
salespersons, 57–58
培训师和技术支持人员，61
trainers and technical support personnel, 61
用户经理，55–56
users’ manager, 55–56
与61–63 岁的人一起工作时该怎么做
what to do when working with, 61–63
定位, 193
positioning, 193
样本, 37
sample, 37
巩固角色，35–36
consolidating roles, 35–36
客户责任，41
customer responsibilities, 41
开发者责任，40
developer responsibilities, 40
极端人物，39
extreme characters, 39
初始用户角色集：
initial set of user roles:
头脑风暴，33-34
brainstorming, 33–34
组织，34-35
organizing, 34–35
现场用户，39–40
on-site users, 39–40
角色，38-39
personas, 38–39
提炼角色，36–37
refining roles, 36–37
角色属性，36
role attributes, 36
南海岸航海用品（示例项目），195–197
South Coast Nautical Supplies (example project), 195–197
介入，33-37
steps in, 33–37
用户角色，31-33
user roles, 31–33
用户角色：
User roles:
属性，36–37
attributes, 36–37
集思广益最初的一组，33-34
brainstorming an initial set of, 33–34
巩固，35-36
consolidating, 35–36
识别, 33
identifying, 33
识别代表单个用户的角色，34
identifying roles that represent a single user, 34
包括在用户故事中，80-81
including in user stories, 80–81
初始组：
initial set of:
头脑风暴，33-34
brainstorming, 33–34
组织，34-35
organizing, 34–35
精炼，36–37
refining, 36–37
角色属性，36-37
role attribute, 36–37
南海岸航海用品（示例项目），191–198
South Coast Nautical Supplies (example project), 191–198
用户故事：
User stories:
优于替代方法的优势，13-14
advantages over alternative approaches, 13–14
方面，4
aspects of, 4
增加需求文档样式，6
augmenting in requirements documentation style, 6
148的可理解性
comprehensibility of, 148
客户责任，155
customer responsibilities, 155
和每日 Scrum 会议，174
and the daily Scrum meeting, 174
和延迟细节，150
and deferring detail, 150
定义，4-5
defined, 4–5
描述，4
descriptions, 4
开发人员的责任，155
developer responsibilities, 155
估计，87-95
estimating, 87–95
方法，88-90
approach, 88–90
客户责任，95
customer responsibilities, 95
开发者责任，94
developer responsibilities, 94
结对编程，92–93
pair programming, 92–93
故事点，87-88，91-92
作为一个团队，88
as a team, 88
三角测量估计，90-91
triangulating an estimate, 90–91
与 IEEE 830 相比，133–136
IEEE 830 compared to, 133–136
和迭代开发，149–150
and iterative development, 149–150
和参与式设计，152
and participatory design, 152
优先排序，98–101
prioritizing, 98–101
和产品积压，173
and the product backlog, 173
错误报告与185之间的关系
relationship between bug reports and, 185
代表用户重视的功能，5
representing functionality valued by users, 5
保留，184–185
retaining, 184–185
场景比较，141-142
scenarios compared to, 141–142
规划尺寸，148–149
size for planning, 148–149
大小，6
size of, 6
在冲刺计划会议中，173-174
in the sprint planning meeting, 173–174
在冲刺审查会议上，174
in the sprint review meeting, 174
支持机会主义发展，151-152
support for opportunistic development, 151–152
隐性知识，建立，153
tacit knowledge, build up of, 153
和技术术语，14
and technical jargon, 14
测试说明，7–8
test descriptions, 7–8
太详细了，19
with too much detail, 19
用例比较，137–141
use cases compared to, 137–141
和用户界面( UI ) ，26、79–80、139–140、159–160、181–183 _ _
and the user interface (UI), 26, 79–80, 139–140, 159–160, 181–183
和口头交流，145-148
and verbal communication, 145–148
用户经理，64岁
Users’ manager, 64
用户故事，初始收集，209–210
Users stories, initial collection of, 209–210
V
V
对购买者/用户的价值，20–22
Value to purchasers/users, 20–22
Velocity, 9–10, 15, 91–92, 113
实际，119–120
actual, 119–120
计算，119
calculations, 119
猜测，104–105
guessing at, 104–105
最初，104–105
initial, 104–105
迭代燃尽图，121–123
iteration burndown charts, 121–123
测量，117–119
measuring, 117–119
测量/监控：
measuring/monitoring:
客户责任，127
customer responsibilities, 127
开发者责任，127
developer responsibilities, 127
计划中，119–120
planned, 119–120
口头交流，145–148
Verbal communication, 145–148
版本一，179
VersionOne, 179
W
W
面向瀑布的流程，8
Waterfall-oriented process, 8
“白皮书”（贝克），234
“White book” (Beck), 234
宽带 Delphi 方法，88
Wideband Delphi approach, 88
维基百科，179
Wikis, 179
威廉姆斯，劳里，237
Williams, Laurie, 237
不会有的功能，发布计划，98–99
Won’t-have features, release plan, 98–99
写故事，17-29
Writing stories, 17–29
综合故事，18
combined stories, 18
结合故事，26-27
combining stories, 26–27
客户责任，28
customer responsibilities, 28
开发者责任，28
developer responsibilities, 28
可估计的故事，22-23
estimatable stories, 22–23
高度依赖的故事，17-18
highly dependent stories, 17–18
独立故事，17-18
independent stories, 17–18
可协商的故事，18-19
negotiable stories, 18–19
小故事，23-27
small stories, 23–27
拆分故事，18
splitting stories, 18
故事大小，23-27
story size, 23–27
可测试的故事，27
testable stories, 27
X
X
XP，参见极限编程 (XP)
XP, See Extreme Programming (XP)
规划师, 179
XPlanner, 179
脚注
Footnotes
[1]本章中对用户角色的大部分讨论都是基于 Larry Constantine 和 Lucy Lockwood 的工作。有关用户角色建模的更多信息，请访问其网站www.foruse.com或Software for Use (1999)。
[1] Much of the discussion of user roles in this chapter is based on the work of Larry Constantine and Lucy Lockwood. Further information on user role modeling is available at their website at www.foruse.com or in Software for Use (1999).
[1]集成测试框架 FIT 可从fit.c2.com 获取。
[1] The Framework for Integrated Test, FIT, is available at fit.c2.com.
[2] FitNesse 可从fitnesse.org 获得。
[2] FitNesse is availabe from fitnesse.org.
[3]有关信用卡有效期的信息，请参阅www.beachnet.com/~hstiles/cardtype.html。
[3] For information on credit card validity, see www.beachnet.com/~hstiles/cardtype.html.
[1] Joshua Kerievsky，邮箱： extremeprogramming @yahoogroups.com ，2003 年 8 月 5 日。
[1] Joshua Kerievsky on extremeprogramming@yahoogroups.com, August 5, 2003.
[1]有关 DSDM 的信息，请参阅DSDM：以业务为中心的开发（Stapleton 2003）。
[1] For information on DSDM see DSDM: Business Focused Development (Stapleton 2003).
[1]改编自The Inmates Are Running the Asylum ( Cooper 1999 )。
[1] Adapted from The Inmates Are Running the Asylum (Cooper 1999).
[2]个人通讯，2003 年 11 月 7 日。
[2] Personal communication, November 7, 2003.
[3] Steve Berczuk ，邮箱： extremeprogramming @yahoogroups.com ，2003 年 2 月 20 日。
[3] Steve Berczuk on extremeprogramming@yahoogroups.com, February 20, 2003.
[4] James Grenning，邮箱： extremeprogramming @yahoogroups.com ，2003 年 2 月 23 日。
[4] James Grenning on extremeprogramming@yahoogroups.com, February 23, 2003.
[1]有关 Scrum 的完整介绍，请参阅使用 Scrum 进行敏捷开发（Schwaber 和 Beedle 2002）。
[1] For complete coverage of Scrum, see Agile Development with Scrum (Schwaber and Beedle 2002).
[1] See www.versionone.net.
[2] See www.xplanner.org
[3]请参阅www.selectbs.com/products/products/select_scope_manager.htm。
[3] See www.selectbs.com/products/products/select_scope_manager.htm.
[1]特别参见极限编程解释：拥抱变化（Beck 2000）、极限编程安装（Jeffries、Anderson 和 Hendrickson 2000）或探索极限编程（Wake 2002）。
[1] In particular see Extreme Programming Explained: Embrace change(Beck 2000), Extreme Programming Installed (Jeffries, Anderson, and Hendrickson 2000), or Extreme Programming Explored (Wake 2002).